nx: @nrwl/angular:component error in v14.6.* and v14.7.*

Current Behavior

I can’t generate component using @nrwl/angular:component.

Expected Behavior

Generate angular component successfully.

Steps to Reproduce

npx create-nx-workspace test
choose angular-nest
run nx g nrwl/angular:library reproduce / nx g lib reproduce
In libs/reproduce/src/lib run nx g @nrwl/angular:component reproduce / nx g component reproduce

Failure Logs

> NX The path provided for the component (libs/reproduce/src/lib) does not exist under the project root (apps/my-app). Please make sure to provide a path that exists under the project root.

Environment

   Node : 14.18.1
   OS   : win32 x64
   npm  : 6.14.15

   nx : 14.6.5
   @nrwl/angular : 14.6.5
   @nrwl/cypress : 14.6.5
   @nrwl/detox : Not Found
   @nrwl/devkit : 14.6.5
   @nrwl/eslint-plugin-nx : 14.6.5
   @nrwl/express : Not Found
   @nrwl/jest : 14.6.5
   @nrwl/js : 14.6.5
   @nrwl/linter : 14.6.5
   @nrwl/nest : 14.6.5
   @nrwl/next : Not Found
   @nrwl/node : 14.6.5
   @nrwl/nx-cloud : 14.6.1
   @nrwl/nx-plugin : Not Found
   @nrwl/react : Not Found
   @nrwl/react-native : Not Found
   @nrwl/schematics : Not Found
   @nrwl/storybook : 14.6.5
   @nrwl/web : 14.6.5
   @nrwl/workspace : 14.6.5
   typescript : 4.7.3
   ---------------------------------------
   Local workspace plugins:
   ---------------------------------------
   Community plugins:
         @nguniversal/express-engine: 14.1.0
         @nguniversal/builders: 14.1.0

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 16 (6 by maintainers)

Most upvoted comments

Just to clarify, when https://github.com/nrwl/nx/pull/11980 lands, you won’t need to provide --project if only the --path is provided in the right place. The project will be inferred from the path in those cases. If you do provide --project and --path, we’ll check whether the path is contained inside the project root.

leosvelperez on Sep 13, 2022

Duplicate of https://github.com/nrwl/nx/issues/11883

It is pretty straightforward to support this where you can just be in the same folder in the terminal as the project you want to generate the component in.

But ideally, the --project flag should be provided

Coly010 on Sep 12, 2022

@ElecTreeFrying, @junekpavel thanks for providing more details about the pain points.

As explained before this is a check that we do to ensure the path being passed belongs to the specified project, to avoid issues related to those properties not being in sync. We use the project and make decisions based on the configuration of the project, so, if the project and the path are not in sync some issues might arise depending on other options provided.

That said, I can see how restrictive it might be in some scenarios. If someone just wants to specify only the path to the component, we should support it. We do need the project, as I mentioned above, but we could infer the project based on the provided path only if the project was not provided. We need to keep the check if both properties are provided. So, the check is still needed but only in certain scenarios.

Once again, thanks for raising this and sticking to it! We’ll work on addressing it.

P.S. Just a quick note to clarify some points made above:

As I understand it, nx is presenting itself as a replacement for Angular CLI. During the installation of nx, the Angular CLI is disabled in favor of nx and the ng command is aliased to nx. So I would expect that every nx command which is replacement to ng would work the very same way as the ng one.

Nx is not just a “replacement” for the Angular CLI. It’s that and much more. The fact that Nx can replace the Angular CLI (it does offer most of the commands of the Angular CLI) doesn’t mean that it has to do everything the same. The point is to offer a superior CLI experience.

There also seems to be confusion between the boundaries of the CLI and the generators offered by plugins. The generate command behaves pretty similar between both Nx and Angular CLI, though they have different implementations. What’s at fault here is not the command nor the CLI used, it’s the generator. The @nrwl/angular:component generator checks that the path is contained in the specified project. The @schematics/angular:component doesn’t.

But the result is not same, as nx throw an error. So I’d suppose, this is bug in nx. And if it’s not, I do believe that the ng command should’t be aliased at all. It should be up to developer which command want to to use.

As explained above, the issue is not the command (generate) nor the CLI (nx vs ng), but the generator/schematic used. You can still run nx g @schematics/angular:component instead of the @nrwl/angular:component. You don’t need to change the CLI that you use for that, Nx can run Angular CLI schematics. In fact, when you run the @nrwl/angular:component generator, the @schematics/angular:component is run under the hood for the base generation, and then we add some features on top of it.

As also explained, the check for the path was a decision made to prevent misusing the generator. Right now we need it for all scenarios because we rely on the default project to populate the project property when none is specified. Based on the discussion here, we could get rid of it when the project option is not provided by inferring it from the path instead of getting the default project.

leosvelperez on Sep 12, 2022

I reverted back to v14.5.10, nx g component works fine and normally. I think something is wrong with v14.6.x releases with @nrwl/angular:component.

ElecTreeFrying on Sep 9, 2022