TypeScript: node_modules/@types cannot be deleted on Windows
Workaround: Run this command to release the lock on the file:
Issue Type: Bug
Probably related to automatic type acquisition. I’ve been seeing this frequently only on Windows:
PS D:\dev\Tyriar\xterm.js> yarn
yarn install v1.10.1
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.4: The platform "win32" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding
it from installation.
[3/4] Linking dependencies...
error An unexpected error occurred: "EPERM: operation not permitted, scandir 'D:\\dev\\Tyriar\\xterm.js\\node_modules\\@types'".
info If you think this is a bug, please open a bug report with the information provided in "D:\\dev\\Tyriar\\xterm.js\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
PS D:\dev\Tyriar\xterm.js>
This is what explorer tells me when I try to go to that folder:
When I close vscode, the @types folder deletes itself.
VS Code version: Code - Insiders 1.31.0-insider (e02e44464c02d617b98d0a3265bf5efef7794436, 2018-12-21T06:20:35.852Z) OS version: Windows_NT x64 10.0.17763
System Info
| Item | Value |
|---|---|
| CPUs | Intel® Core™ i5-4670K CPU @ 3.40GHz (4 x 3398) |
| GPU Status | 2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled |
| Memory (System) | 15.94GB (9.26GB free) |
| Process Argv | |
| Screen Reader | no |
| VM | 0% |
Extensions (11)
| Extension | Author (truncated) | Version |
|---|---|---|
| vscode-svgviewer | css | 1.4.7 |
| emulate | Die | 0.0.7 |
| EditorConfig | Edi | 0.12.6 |
| tslint | eg2 | 1.0.42 |
| vscode-npm-script | eg2 | 0.3.5 |
| git-project-manager | fel | 1.7.1 |
| vscode-pull-request-github-insiders | Git | 0.354.0 |
| cpptools | ms- | 0.21.0-insiders2 |
| material-icon-theme | PKi | 3.6.2 |
| polacode | pnp | 0.2.2 |
| vscode-todo-highlight | way | 1.0.4 |
(1 theme extensions excluded)
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 80
- Comments: 50 (13 by maintainers)
This really makes the experience bad on Windows, any time I git clean i need to reload the vscode window.
Hey everyone, just to clarify: we intend to fix this bug in the TypeScript 3.5 milestone
FWIW using this command before deleting
node_moduleshelps.Doesn’t help that the issue is closed in both the TypeScript repo and the vscode repo, despite people still being directed here
@biltongza they’re way too busy handling real issues with VScode like the santa hat on the settings cog
@DanielRosenwasser is anyone looking at this? It’s a serious regression that makes the VSCode+TypeScript user experience seem glitchy and not professional. I encounter it every day. If there’s no easy fix, maybe we can at least figure out what compiler version everyone needs to downgrade to. (Or revert whatever PR caused it.) Help us, Obi-Wan Kenobi! 😃
@sheetalkamat a year has passed since this bug was reported, and despite the electron bugfix it is clear that the issue is not completely resolved as my entire team still experiences this issue along with multiple other people reporting it here over the past few months. Please can we reopen this bug?
this STILL happens with TS 3.7.2 and VSCODE 1.40.1
After investigating this further it turns out the issue lies in vscode (internally in electron it uses). There is no workaround for this since the watcher when invoked doesn’t reflect the directory being deleted so there is no way to know that watcher can be closed or changed to fallback to missing watcher. Error event handler for watcher is not invoked as well.
Upon discussing this with @mjbvz it turns out vscode insiders has this fixed (electron 3.1.8) by electron/node#97
In the past couple months, a lot of people have started reporting this issue when working in our monorepo. If there’s no quick fix, is there a PR that can be temporarily reverted to restore the old behavior? Or is there a way to downgrade the tsserver version used by VS Code IntelliSense?
For the record this is much more than just @types having an issue. If you leave vs code open for a while and update packages etc with npm update or npm install and then without anything open rimraf node_modules it will fail and will fail on other module deletes.
Further even if no @types vscode won’t delete the node_modules folder itself.
Further, even rimrafing modules within the node_modules folder if you have opened a file that has an import statement from that module will cause the same issue: unlink error.
This is chronic and really screwing with workflows and wasting time for devs and STILL exists 8/8/2019 in the latest vs code using angular as an example.
I’m pretty sure I hit this again after this was closed, I just might not be noticing it as much as I’m doing more development via remote ssh on a Linux VM. Before this closed I did verify launching VS Code, running yarn watch and waiting for intellisense followed by
git clean -xfdwhich worked, so maybe this is triggered somehow after TS Server has been up for a while? 🤷♂Is there a version that doesn’t have this defect?
Yeah that’s my issue. Same thing as this issue but I use VS2019, not VScode. I have a project it reliably happens on but it’s private. Hard to reproduce in a new project and I don’t have a ton of time to put into it. Could have something to do with switching branches, not sure.
Or maybe npm link, via lerna. Or babel+webpack. Lots of variables.
This is definitely still happening, please reopen the issue.
Version: 1.36.0-insider (user setup) Commit: b7265738444f1eee05762341b4361ee6452a4154 Date: 2019-06-27T05:22:06.378Z Electron: 4.2.5 Chrome: 69.0.3497.128 Node.js: 10.11.0 V8: 6.9.427.31-electron.0 OS: Windows_NT x64 10.0.18362 TS: 3.5.2
I did a VS Code build (yarn watch), it failed with:
Immediately after I restart TS server and ran
yarn watchagain and it worked, here’s the full output:You can Reload Window
@biltongza the option shows up when you have a js/ts file open.
A temporary fix for this is to close your close your editor, then
node_moduleswill be automatically deleted. You only need the current editor. You do not need to close all of your vscode editors. Another little trick if you are trying to wipe your whole node_modules is to manually delete @types first, and then delete node_modules.This still exists as of August 2021. I’m having the same error messages as @nharrer and this is a major annoyance.
I installed the current insiders build:
But I am still struggling deleting node_modules:
And then after Continue:
After a “Typescript: Restart TS Server” the delete works (or after closing VSC).
I am a big fan of VSC. This is one of the few quirks (probably the only one) that constantly bogs me down. Sometimes it also happens when updating packages. Or when rebuilding local libraries which are installed with npm link. Or even when you want to delete or move directories in your project. “Restart TS Server” helps. But since TS immediately starts scanning files again it’s a hit and miss.
@biltongza you can restart your vscode
Added a workaround to the top issue that’s much better than reloading the window.
It’s probably best to continue discussion in the open dupe issue https://github.com/microsoft/TypeScript/issues/32113. They need reliable repro steps.
@octogonz To change your typescript version follow these instructions
Similar to what @Tyriar said, I was only able to finally run
npm updateafter I rannpm cache verifyONLY if I closed VSCode before runningnpm update(I’m on Windows 7).When I try to delete this folder, it tells me I require permission from the computer’s administrator to make changes to the folder. I AM the computer’s administrator.
BUT THEN…
I restarted my computer and the folder was gone.
I have investigated this and it seems like when built folder is deleted by gulp build, node doesn’t notify us correctly and goes in bad state instead before executing “error” handler.
used repro from: https://github.com/Microsoft/vscode/issues/68576#issuecomment-463865605
This is how I’ve been seeing this most of the time:
I also see this issue but I have
typescript.disableAutomaticTypeAcquisition: trueset, I install all@typesmanually.