Typescript: node_modules/@types cannot be deleted on Windows

[frattaro]

Search Terms:
is:issue is:open "visual studio"

Code
npm run reset
"reset": npx rimraf node_modules
"devDependencies": { ...babel }

Expected behavior:
node_modules files are deleted

Actual behavior:
error:
EPERM: operation not permitted.... blah blah... node_modules/@babel/types/lib/index.js.flow

Related Issues:
Exactly this issue (https://github.com/microsoft/TypeScript/issues/29407) but instead of VSCode it doesn't work in VS2019 (16.1.3 on windows 10)

[RyanCavanaugh]

We would need actual repro steps to investigate. Please provide and unassign yourself. Thanks!

[ErikHumphrey]

See also https://github.com/Microsoft/vscode/issues/72535. Pretty annoying to have to close the editor just to build Ng/TS projects, losing undo history. (Assuming it wasn't fixed in TS 3.5 and is a TS issue rather than a VS or VS Code one...might be fixed in the Insider build, though!)

[Tyriar]

@RyanCavanaugh please close this and reopen #29407, see https://github.com/microsoft/TypeScript/issues/29407#issuecomment-506435971

[RyanCavanaugh]

We'd prefer to start with a new issue since there is likely a second root cause that needs investigating. Thanks!

[Tyriar]

@RyanCavanaugh no action was taken to "fix" the old issue and I'm pretty sure it was ever fixed, just not verified correctly. https://github.com/microsoft/TypeScript/issues/29407 has 51 votes and should still be treated as your #2 voted bug.

[biltongza]

29407 was closed as an issue with electron, but this issue shows that there is another issue with the same symptoms since this one is about VS2019, which doesn't use electron as far as I'm aware.

[ErikHumphrey]

See also https://github.com/Microsoft/vscode/issues/72535

I didn't get this issue using npm install, but it can be reproduced 100% of the time using npm ci (https://github.com/microsoft/TypeScript/issues/32113#issuecomment-510160702).

Edit: Also, building sometimes gives a bunch of ENOENT: no such file or directory (-4058) errors instead of the EPERM one.

[RyanCavanaugh]

We're very happy to fix bugs with repros! Please help us 😢

[biltongza]

Repro (for an angular project at least, extensions disabled):

ng new (accept all defaults)
open vscode
open main.ts so tsserver starts
npm ci

D:\scratch\vscode-issue [master]> npm ci npm WARN prepare removing existing node_modules/ before installation npm ERR! path D:\scratch\vscode-issue\node_modules\@angular-devkit\build-angular npm ERR! code EPERM npm ERR! errno -4048 npm ERR! syscall unlink npm ERR! Error: EPERM: operation not permitted, unlink 'D:\scratch\vscode-issue\node_modules\@angular-devkit\build-angular' npm ERR! [OperationalError: EPERM: operation not permitted, unlink 'D:\scratch\vscode-issue\node_modules\@angular-devkit\build-angular'] { npm ERR! cause: [Error: EPERM: operation not permitted, unlink 'D:\scratch\vscode-issue\node_modules\@angular-devkit\build-angular'] { npm ERR! errno: -4048, npm ERR! code: 'EPERM', npm ERR! syscall: 'unlink', npm ERR! path: 'D:\\scratch\\vscode-issue\\node_modules\\@angular-devkit\\build-angular' npm ERR! }, npm ERR! stack: "Error: EPERM: operation not permitted, unlink 'D:\\scratch\\vscode-issue\\node_modules\\@angular-devkit\\build-angular'", npm ERR! errno: -4048, npm ERR! code: 'EPERM', npm ERR! syscall: 'unlink', npm ERR! path: 'D:\\scratch\\vscode-issue\\node_modules\\@angular-devkit\\build-angular' npm ERR! } npm ERR! npm ERR! The operation was rejected by your operating system. npm ERR! It's possible that the file was already in use (by a text editor or antivirus), npm ERR! or that you lack permissions to access it. npm ERR! npm ERR! If you believe this might be a permissions issue, please double-check the npm ERR! permissions of the file and its containing directories, or try running npm ERR! the command again as root/Administrator (though this is not recommended).

CPUs | Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2904)
-- | --
GPU Status | 2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled
Load (avg) | undefined
Memory (System) | 15.90GB (6.58GB free)
Process Argv | --folder-uri file:///d%3A/git/PlatformWeb/ClientApp
Screen Reader | no
VM | 0%

Extensions: none

Windows 10 1903 Build 18362.207, but it also happens to my colleagues on 1809.

[frattaro]

That's the error I was getting with Visual Studio 2019 on a Vue project, running rimraf on node_modules. Unfortunately I can't share the project, and I'm having trouble reproducing, and little time to work on it.

My co-workers didn't have any issues on their apple laptops.

[RyanCavanaugh]

@biltongza I just ran exactly those steps without any problems

[biltongza]

I just reran the exact steps I used, no issues this time 🤷‍♀️ Perhaps it's a timing issue? It looks like you are using node 10, I am using 12 but I had the same issue when I was using 10. Sometimes when we have this issue, we can give it a minute or so and try run it again and it works, but it's extremely frustrating having to delay like that because it's wasting time.

Our workaround for this is to close vscode completely, npm ci, then open vscode again which means waiting for tsserver to start up again which is also wasting time.

We have another issue that I am certain is related. We have an in house NPM package that we use in 2 separate projects. Our procedure to test with this is npm run build in the package, then cd dist/foo/bar and then npm link. Then we open the project in which we use the package, then npm link @foo/bar. This usually works first time, but any changes requiring us to rebuild the NPM package has this same issue where it can't delete files. Sure enough, if you close vscode, building suddenly works. Building also works if you give it a while to let go of files.

I am sure this is a Windows only problem since in Unix land you can do what you want to files that are being used by other processes, while in Windows land there are restrictions around that. What I can't fathom though is that these files are getting locked in dist/ which surely shouldn't be touched by tsserver since they aren't source files?

I am at a point now where I'm so frustrated with this issue that I have a Linux VM running that I can use the remote development SSH extension with, just so I can avoid this.

Update: I just restarted tsserver and tried to npm ci while it was starting up, and I could reproduce the issue.

[ErikHumphrey]

Yes, it's probably a Windows-only issue. I've heard that Unix-like operating systems don't actually delete the files/folders until the last handle is closed.

[JohnGalt1717]

BTW, this happens not just with @types. I'm seeing it with even other modules (momentjs etc) in vs code with typescript. Anything that a file has been opened and references will block it for about 3 tries.

And this also affects ng build for component libraries as well.

[biltongza]

I am also able to reproduce this by running npm ci, then immediately afterwards trying to run it again.

In this instance, I used process explorer to see what was holding on to the node_modules folder:

As you can see, there's a lot open there.

This is the command line for PID 16040:
"C:\Program Files\Microsoft VS Code\Code.exe" c:\Users\logan.dam\.vscode\extensions\angular.ng-template-0.802.3\server\server.js --logFile c:\Users\logan.dam\AppData\Roaming\Code\logs\20190902T123650\exthost1\Angular.ng-template\nglangsvc.log --node-ipc --clientProcessId=6148

I wasn't able to find that log file it points to, but I did find C:\Users\logan.dam\AppData\Roaming\Code\logs\20190902T123650\exthost1\output_logging_20190902T123715\5-Angular Language Service.log which contains MANY lines similar to Detected source file changes: d:/git/PlatformWeb/ClientApp/node_modules/...

I am starting to wonder if this is an angular issue.

Also, is it possible that the issue is caused by having typescript.tsdk set to "node_modules/typescript/lib" in settings.json?

[collinsauve]

I am starting to wonder if this is an angular issue.

I experience this in several React projects that have no angular in them.

[NickSeagull]

I'm experiencing this on a back-end only project. I'm trying to move the node_modules folder for a deploy that I perform, and it fails with permission denied.

[Pike96]

Have been tracking this issue for more than half a year, also have given up on VSCode for that long. Cannot believe that this is still a problem.

In my case, I have several local ts libraries that output to dist folder. My main app relies on those libraries, and also output to dist folder. There are .ts files in my libraries' output files. So TS server in VSCode holds the files in dist, which prevent me from deleting dist folder before building the whole thing. If I disable typescript-language-features, then the problem is gone.

All related issues that I can found for my problem are closed and point to #29407 and this one.

[Tyriar]

@RyanCavanaugh I don't think this should be assigned to the OP? Also can you label with VS Code Priority?

[sheetalkamat]

I think we need a reliable repro .. so far we haven’t been able to repro it since the electron issue fix...

[fksik]

I am experiencing the same problem as mentioned by @Pike96 unable to delete the dist folder with multiple libraries, If i restart the tsserver of reload the window Iam able to delete the folder, But this is making my build process slow

[budajeff]

My setup and situation is the same as @Pike96 . VS Code/tsserver is holding lock on lots of my project's source code files (which aren't open in VS code editor tabs) and lots of node_modules\ files. Restarting the tsserver is my work-around.

[sondreluc]

Me and my entire team are also experiencing this same problem when working with our React application code base.
I've tried to create a reliable and minimal reproduction project, but have not been able to reproduce the problem with a new, minimal react project...
This leads me to believe that it can have something to do with what (or amount of) dependencies (eg. @types/*) you have in our project?

[sebastiangug]

This still happens to me all the damn time with TS 3.7.2
VSCODE:

Version: 1.40.1 (user setup)
Commit: 8795a9889db74563ddd43eb0a897a2384129a619
Date: 2019-11-13T16:49:35.976Z
Electron: 6.1.2
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.18362

Multiple windows 10 machines, same behaviour since forever.

[hhlevnjak]

A similar issue for me, running the local build for a node/react project (no typescript here). The build involves rimraf-ing the old build folder which fails with the same error as above.

I get the same problem when trying to delete the node_modules folder.

Restarting VS Code or just restarting the TS server fixes the problem.

The trouble with reproducing it is, it doesn't happen every time (which is an improvement from the VS code versions a while back). So probably the TS server has a lock on the files at some point.

[ErikHumphrey]

Can't provide any more logs, but this error appeared right after a clean install of Windows on a new computer

[rkeithhill]

We are running into this as well on our team. When we do a clean build, the build fails on a rimraf of one of our node_modules dirs. I've tried restarting the TS server and that doesn't really help. SysInternals' handle.exe shows the folder as locked by code.exe:

Code.exe           pid: 23548  type: File           508: C:\Users\hillr\Git\KLM\src\KalManagement\dist\kal-management\node_modules
Code.exe           pid: 23548  type: File           50C: C:\Users\hillr\Git\KLM\src\KalManagementAppServices\dist\kal-management-app-services\node_modules
Code.exe           pid: 23548  type: File           510: C:\Users\hillr\Git\KLM\src\KalManagementAppServices\node_modules
C:\Users\hillr
12-05 12:32:25 2> get-ntprocess 23548 | % CommandLine
"C:\Program Files\Microsoft VS Code\Code.exe" --max-old-space-size=3072 "c:\Program Files\Microsoft VS Code\resources\app\extensions\node_modules\typescript\lib\tsserver.js" --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName C:\Users\hillr\AppData\Local\Temp\vscode-typescript\a046e5a7634361593230\tscancellation-2191af9d140a955dee64.tmp* --locale en --noGetErrOnBackgroundUpdate --validateDefaultNpmLocation

But the command line shows that instance of code.exe is running the tsserver. This is driving our team crazy. Having to exit VSCode just to do a build is a PITA.

[cinderblock]

I've observed this happens more reliably after the repo has been open for some time and I've been editing things. Package downgrades can relatively reliably make the problem happen.

It's pretty clearly some part of Code.exe holding open file handles and Windows is preventing deletion of "in use" files. I've confirmed that it's Code.exe (and likely not some sub process execution) with SysInternals's tools, similar to how @rkeithhill did above.

I'm not super familiar with how extensions work in VS Code. I feel like these problems happen more in projects that have Prettier or ESLint extensions active. Like their crawling of files crashes poorly.

[luchillo17]

I keep having locks like this whole issue suggests, happens mostly when i want to rename a folder that isn't at the bottom level, say the folder has only files in it, all good with the rename, but if it has more folders, it throws EPERM error at me in the Log (Window) output:

And i am indeed in a project with TypeScript (Angular) and Prettier, but disabling TS can't be done and disabling Prettier doesn't help.

In fact after noticing this i went testing renaming folders empty, only files inside, and with folders inside, and is very consistent the issue with the renames when the folder has nested folders inside, i could change 1 level folder name between 2 attempts at 2 level nested folder rename.

[sheetalkamat]

Closing this so anyone who still faces issue can open new issue with concrete steps to repro and be able to investigate