Plugin interferes with the deletion of the node_modules

[Den-dp]

Current Behavior

It is impossible to fully remove node_modules while in IDE

Expected Behavior

Unfortunately, developers in the npm ecosystem are used to removing the node_modules folder in some cases.
Currently, it is problematic while in IDE because the plugin locks resources in node_modules/@nx/.
Such adds extra overhead on communicating that IDE must be closed in order to do such things, while theoretically can be solved one time on your side.

Steps to Reproduce

1. npx create-nx-workspace@latest nx1672
2. idea nx1672 or code nx1672
3. nx reset (to stop the daemon?)
4. rm -fo -r node_modules (I'm using powershell)

Failure Logs / Images / Videos

rm -fo -r node_modules
Cannot remove C:\nx1672\node_modules\@nx\.nx-win32-x64-msvc-kycqiCtG\nx.win32-x64-msvc.node: Access to the path 'nx.win32-x64-msvc.node' is denied.

Environment

 >  NX   Report complete - copy this into the issue template

   Node   : 16.14.2
   OS     : win32-x64
   npm    : 9.8.1

   nx (global)        : 16.7.2
   nx                 : 16.7.2
   @nx/js             : 16.7.2
   @nx/jest           : 16.7.2
   @nx/linter         : 16.7.2
   @nx/workspace      : 16.7.2
   @nx/angular        : 16.7.2
   @nx/cypress        : 16.7.2
   @nx/devkit         : 16.7.2
   @nx/eslint-plugin  : 16.7.2
   @nrwl/tao          : 16.7.2
   @nx/webpack        : 16.7.2
   typescript         : 5.1.6

• Nx Console: v18.6.0

• VSCode: 1.82.0-insider

• Nx Console: 1.11.1

• IDEA: 2023.2

[Cammisuli]

I know exactly why this happens. It's because of the daemon holding on to the binary file within node_modules. It's a tough issue to solve, and I couldn't think of a way to handle this that isn't a hack.

The simplest way right now is to make sure to stop the daemon first with nx daemon --stop and then remove node_modules. I know it's annoying, because I feel the pain of that as well.

[puschie286]

@Cammisuli and what do you do in non nx projects ? there is no nx installed

[Cammisuli]

The language server will just live and do nothing. It wont be able to get nx projects if there's no nx daemon.

[puschie286]

@Cammisuli im not sure what you mean - i have the same problem, that nx console create the locked file in non nx projects and makes it impossible to delete node_module ( or update/install with yarn )

[MaxKless]

are you on the latest version of Nx Console? We released a fix for non-nx projects a while back.

[puschie286]

im on 1.51.1
the file is created on every yarn install (except when everything is up-to-date), but its not locked. not sure which action cause the locking

[Cammisuli]

If you do not have Nx as a dependency in your workspace, then the .node file that gets locked shouldn't be there. That file only gets locked when the Nx daemon is running, which Nx Console will start.

If the file is there, then there's something that has nx as a dependency, and you can check it with yarn why nx.

If Nx isn't there, then Nx Console won't be able to start the daemon, and it wont lock any files.

[Den-dp]

I couldn't think of a way to handle this that isn't a hack

What if NX will install its binaries in temp folder (e.g. %temp%/.nx/.nx-win32-x64-msvc-kycqiCtG/nx.win32-x64-msvc.node) and use it from there?

I know this is also a hack, but I guess if done that way — there will be no issues with node_modules being locked by nx daemon 🤔

I've seen a similar pattern in Playwright, where

• they store all needed binaries with different versions in one place
  https://playwright.dev/docs/browsers#managing-browser-binaries
• they even do cleaning if needed
  https://playwright.dev/docs/browsers#stale-browser-removal

[puschie286]

@Cammisuli
it looks like '@angular-eslint/builder' has a reference to nx

=> Found "[email protected]"
info Reasons this module exists
   - "@angular-eslint#builder" depends on it
   - Hoisted from "@angular-eslint#builder#nx"
   - Hoisted from "@angular-eslint#schematics#nx"
   - Hoisted from "@angular-eslint#builder#nx#@nrwl#tao#nx"

Nevertheless, nothing should change the node_modules except the package manager - why dont you use the .nx directory that get created anyway ?

[Cammisuli]

@Den-dp thats the current plan that we thought of, but we'd have to move the whole node_modules/nx directory because of the way we use the native binaries.

@puschie286 ok, that makes sense then. Nothing is being changed in the node_modules folder, its just when the daemon gets started (because we found nx in node_modules) it will load a binary file into its memory. And if that daemon is still being run when trying to clean node_modules, the OS cannot remove the .node binary because its in use.