What are the benefits of the new .nx folder location?

[Den-dp]

I've found that in nx@17 the .nx folder was moved from node_modules/.cache to the workspace root.

I don't have strong opinions regarding this, but curious about what this movement solves and whether it can be used to address nrwl/nx-console#1863 ?

[calliope-codes]

In my personal experience, moving the nx cache outside the node_modules folder helps with a few things:

• Easier to restore and save node_modules and nx caches separately in parallel, particularly in CI.
• Easier to use .*ignore files on one or the other folder.
• Easier to mount specific folders for containerized builds (especially in local environments): for example, in a Docker dev environment build stage, mounting the ./node_modules folder as a bind mount, the nx cache as a cache mount, and running a build. (If the NX cache were inside node_modules, the build would try to write the cache to the bind-mounted ./node_modules folder, which is not allowed by Docker.) This is just an example, and I would not recommend it as a general practice.
• Easier to modify or remove the node_modules folder without disturbing the .nx cache.

I took a brief look at your linked discussion, and I think the simplest answer is to create scripts in your package.json. For instance, you could create a script that stops the nx daemon, rm -rf node_modules, and starts the daemon again. In general, you can significantly speed up your development workflow with these sorts of simple, composable commands. Here is an example:

  {
    "reset": "pnpm run stop:nx && pnpm run reset:node_modules && pnpm run start:nx",
    "stop:nx": "nx daemon --stop",
    "reset:node_modules": "rm -rf ./node_modules && pnpm install",
    "start:nx": "nx daemon --start"
  }

[vigneshTheDev]

How do we resolve conflicts, if any? Are there any commands that would regenerate these files?