nx
nx copied to clipboard
Nestjs fails on code change in sublibs, NX ENOTEMPTY: directory not empty in random lib
Current Behavior
I have just updated from 15.0.13
to 16.2.2
, we have multiple apps served in separate terminals.
They have shared libs.
When I change code in the lib, services that depend on that get message to change.
File change detected. Restarting...
and some of them fail with NX ENOTEMPTY: directory not empty, rmdir ... some random dir, especially when you change the file before it finishes the recompilation
Expected Behavior
App recompiles without any issues
GitHub Repo
No response
Steps to Reproduce
- install
16.2.2
- several apps which share multiple libraries
- make a change in the library
- watch as it sometimes fails to restart, and the process is dead. Even if it will not fail, it recompiles ... terribly long (2 minutes after adding one
console.log
in some interface only file), previously it was instant.
Nx Report
Node : 18.14.0
OS : win32 x64
npm : 9.3.1
Hasher : Native
nx : 16.2.2
@nx/js : 16.2.2
@nx/jest : 16.2.2
@nx/linter : 16.2.2
@nx/workspace : 16.2.2
@nx/angular : 16.2.2
@nx/cypress : 16.2.2
@nx/devkit : 16.2.2
@nx/eslint-plugin : 16.2.2
@nx/express : 16.2.2
@nx/nest : 16.2.2
@nx/node : 16.2.2
@nrwl/tao : 16.2.2
@nx/webpack : 16.2.2
typescript : 4.9.5
---------------------------------------
Community plugins:
@ngneat/transloco : 4.2.7
@ngrx/effects : 15.4.0
@ngrx/entity : 15.4.0
@ngrx/router-store : 15.4.0
@ngrx/store : 15.4.0
@ngrx/store-devtools : 15.4.0
apollo-angular : 4.2.1
devextreme-angular : 22.2.6
Failure Logs
No response
Operating System
- [ ] macOS
- [ ] Linux
- [X] Windows
- [ ] Other (Please specify)
Additional Information
No response
can confirm this for 15.6.3 also. Typically happening when the VSCode extension is running.
npm ci
also is then not possible.
This is also happening on one of our projects also which is not using nestjs. One variant of the error we've seen is:
Error: ENOTEMPTY: directory not empty, rmdir '<redacted>/node_modules/.cache/nx/5973e363644dc151f9ab06d9d49c6f59e69ce02bbfac9529018f9a9ac573b43d/outputs/packages/infra/cdk.out/asset.cecf4b5f93b41843286e40690e3ac898434251c4c88bc51660a6701b46c8e5ec/static/js'
Running nx reset
and then rebuild resolves this issue. There must be a bug in the cache population where if a package hash matches one that exists it is trying to re-populate the entry and is doing so incorrectly.
This is also happening on one of our projects also which is not using nestjs. One variant of the error we've seen is:
Error: ENOTEMPTY: directory not empty, rmdir '<redacted>/node_modules/.cache/nx/5973e363644dc151f9ab06d9d49c6f59e69ce02bbfac9529018f9a9ac573b43d/outputs/packages/infra/cdk.out/asset.cecf4b5f93b41843286e40690e3ac898434251c4c88bc51660a6701b46c8e5ec/static/js'
Running
nx reset
and then rebuild resolves this issue. There must be a bug in the cache population where if a package hash matches one that exists it is trying to re-populate the entry and is doing so incorrectly.
we also have the same issue as you mentioned
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏
I am not using nestjs and I have the same problem:
> NX ENOTEMPTY: directory not empty, rmdir '\\?\C:\Users/xxx/src/somefolder'
I think @AgentEnder is probably the right person to comment and finish reviewing the PR I'll assign this to him.
There's been a few fixes since Nx 16.2 that should address this issue:
- Cache is no longer in
node_modules/.cache
by default, so these files should not prevent the directory from being removed. - Nx Console (the vscode/intellij extension) no longer prevents
node_modules
from being removed. - Fixes to
@nx/js:node
executor makes it more resilient to file changes.
If you experience issues with the latest Nx version, please open a new issue with a repro so we can debug.
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.