toolsplus
When running the `register` executor on nx v21, it installs the `@nx/key` package randomly.
Hello!
For some reason after upgrading to nx v21 in our monorepo, running the register executor from this nx plugin installs the @nx/key npm package and then promptly errors out. This package is only needed with Nx's powerpack setup and breaks things if installed without having an enterprise setup. This doesn't happen with any other executors or generators as far as I am aware. If I revert back to v20 via git it runs without any trouble.
This might possibly be an issue since the forge package is on nx v20? or is there a naming collision between the register command from this plugin and some inferred executor from an nx plugin?
Running the forge register manually doing npx nx forge <project-name> register <forge-app-name> works just fine. Though not a great workaround since you have to manually copy paste the new registered ID from the dist to the real manifest.
Hey @zjkipping, thanks for the report. I might have seen this before, but I can't recall what I did to fix it. I did some testing just now and created a new Nx 21 workspace by following the nx-forge setup guide, which worked without any issues. In my case, I called the register executor from the Nx Console UI in Webstorm. I will also try with the nx-forge-examples repo and see what we get.
Do you have any way to reproduce the issue outside of your monorepo?
Hey @tbinna, I have more information below for you. I don't think I need to do a reproduction repo based on it, but let me know if you still need one!
I tracked down what is happening at least, but I'm not 100% sure why. I believe Nx is instead calling it's own "register" command that was added recently if I run the command npx nx register <forge-project-name> --appName=<forge-app-name>.
I believe running executors via the nx console does it with the run nx command with the target suffixing the project name like below:
npx nx run <forge-project-name>:register --appName=<forge-app-name>
This variant of running the executor does actually work; so, I'll tell my folks to use the above command instead for now. I tend not to use the run nx command since it's makes things a little less obvious to me in terms of what is happening.
Here is the code in the Nx repo that it's calling: https://github.com/nrwl/nx/blob/ee7dbf9c3af68985628034f763ca17295c13e1a8/packages/nx/src/utils/require-nx-key.ts#L4
It was added in this feature merge of Nx: https://github.com/nrwl/nx/commit/a2e05c95da80ead7f28e7642359fc1579e0899a8#diff-747265472eab92ab649ea7142a6d8e963ca70badabb30f4af942b81c72a9dc65
This might be an unfortunate result of commands / executors overriding each other given that everything is inferred now...
Might be something to open an issue with on the Nx side?