Cannot find configuration for '*' using readProjectConfiguration [@nx/react:library]

[andersonba]

Current Behavior

After updating from Nx 16 to Nx 17, my custom generator that internally utilizes "@nx/react:library" has started experiencing an issue. Specifically, the problem arises when I attempt to read the project configuration with readProjectConfiguration(tree, projectName) immediately following the generator's execution. This results in a Cannot find configuration for 'folder-my-example' error. My generator operates by passing predefined values and making file adjustments after running the Nx generator. This issue is particularly troublesome as it disrupts the normal workflow that was functional in Nx 16.

Unusual Finding During Debugging

While debugging by directly tweaking the '@nx/react' generator in 'node_modules,' I encountered an oddity: the project name wasn't correctly recognized in Nx's projects map. Specifically, using 'importPath' incorrectly set the path as the project 'name,' leading to retrieval issues. Similarly, incorporating '/' in the project name didn't convert to hyphens ('-') as in prior Nx versions, disrupting standard name formatting and recognition. This issue was evident during the debugging process, as seen in the provided screenshot.

I manually modified the file in node_modules, adding some console.log statements for debugging purposes.

Expected Behavior

The expected behavior is for the custom generator to seamlessly integrate with the updates in Nx 17, just as it did with Nx 16. The readProjectConfiguration function should correctly retrieve the configuration for the newly created project without throwing an error, regardless of whether the project name includes a folder path (e.g., 'folder/my-example').

GitHub Repo

No response

Steps to Reproduce

1. Use Nx 17.
2. Run a custom generator that internally uses "@nx/react:library", create library for "folder/my-example" project and tries to read the project configuration after execution.
3. Observe the error Cannot find configuration for 'folder-my-example' when the project name includes a folder path.

Nx Report

>  NX   Report complete - copy this into the issue template

   Node   : 18.17.1
   OS     : darwin-arm64
   pnpm   : 7.32.0

   nx                 : 17.0.2
   @nx/js             : 17.0.2
   @nx/jest           : 17.0.2
   @nx/eslint         : 17.0.2
   @nx/workspace      : 17.0.2
   @nx/cypress        : 17.0.2
   @nx/devkit         : 17.0.2
   @nx/eslint-plugin  : 17.0.2
   @nx/nest           : 17.0.2
   @nx/next           : 17.0.2
   @nx/node           : 17.0.2
   @nx/plugin         : 17.0.2
   @nx/react          : 17.0.2
   @nx/rollup         : 17.0.2
   @nx/storybook      : 17.0.2
   @nx/vite           : 17.0.2
   @nx/web            : 17.0.2
   @nx/webpack        : 17.0.2
   typescript         : 5.1.6
   ---------------------------------------
   Community plugins:
   @currents/nx        : 2.0.1
   @nx-tools/nx-docker : 3.0.3
   ---------------------------------------
   Local workspace plugins:
         @jusbrasil-web/nx-tools

Failure Logs

No response

Package Manager Version

pnpm 7.32.0

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Additional context
Upon diving into the Nx source code, I noticed that this issue seems specific to '@nx/react'. In contrast, the '@nx/js' library, which follows the same approach, does not exhibit this problem.

As a further attempt to resolve the issue, I tried providing the "projectNameAndRootFormat" explicitly, suspecting the problem might be related to how the 'derived' configuration handles project names with parent folders. Notably, if I avoid using a parent folder in the name (e.g., using no-folder-my-example), the project is created without any issues.

[andersonba]

Performing the same test using @nx/js:library instead of @nx/react:library leads to a different outcome. Here, the project is found, and everything works correctly. The screenshot shows this contrast, using the same debug method and commands from the issue.

[andersonba]

Another observation relates to the package.json. When "@nx/react:library" (publishable) creates the package.json using the importPath, it appears to treat this import path as the project name within Nx's project context. Currently, I have pnpm workspaces set up for the libs folder to facilitate publishing using changesets.

The critical note here is: if I disable pnpm workspaces, everything starts working again. That is, the project is correctly identified by its name "shared-abc" instead of "@web/shared-abc". However, what's peculiar is that with "@nx/js:library", despite simulating the same behavior and generating an identical package.json with the importPath as the name, this issue doesn't manifest. This remains true whether pnpm workspaces is enabled or disabled.

This suggests some inconsistency or unexpected interaction in the way "@nx/react:library" is handling project naming and its relationship with package.json and pnpm workspaces.

[andersonba]

Fixed in version 17.1.0-beta.0 by #19874

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.