Closed Tyriar closed 5 years ago
I also see this issue but I have typescript.disableAutomaticTypeAcquisition: true
set, I install all @types
manually.
Sometimes I see similar problem (but with random folders/files inside node_modules), closing vscode doesn't help, explorer shows unknown folder/file owner. Unmounting and then mounting volume helps. I think it's some ntfs bug.
This is how I've been seeing this most of the time:
PS C:\Users\daimms.REDMOND\Documents\dev\Microsoft\vscode> yarn
yarn install v1.10.1
$ node build/npm/preinstall.js
[1/4] Resolving packages...
[2/4] Fetching packages...
info vscode-fsevents@0.3.10: The platform "win32" is incompatible with this module.
info "vscode-fsevents@0.3.10" is an optional dependency and failed compatibility check. Excluding it from installation.
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...
warning " > gulp-tsb@2.0.5" has incorrect peer dependency "typescript@^2.0.10".
error An unexpected error occurred: "EPERM: operation not permitted, lstat 'C:\\Users\\daimms.REDMOND\\Documents\\dev\\Microsoft\\vscode\\node_modules\\@types\\commander\\node_modules\\commander'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\daimms.REDMOND\\Documents\\dev\\Microsoft\\vscode\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.`
Moving upstream as the lock does seem to be held by the TS Server. Here's the process I see with a handle to the @types
dir:
"C:\Users\matb\AppData\Local\Programs\Microsoft VS Code Insiders\Code - Insiders.exe" "c:\Users\matb\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\extensions\node_modules\typescript\lib\tsserver.js" --useInferredProjectPerProjectRoot --enableTelemetry --cancellationPipeName C:\Users\matb\AppData\Local\Temp\vscode-typescript\tscancellation-bdabea66566bf0537af9.tmp* --logVerbosity verbose --logFile "c:\Users\matb\AppData\Roaming\Code - Insiders\logs\20190102T150306\exthost1\vscode.typescript-language-features\tsserver-log-AfClj4\tsserver.log" --locale en --noGetErrOnBackgroundUpdate
This really makes the experience bad on Windows, any time I git clean i need to reload the vscode window.
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
Yes, the permission errors are caused with some deletions. Thanks for your repro.
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.
FWIW using this command before deleting node_modules
helps.
So does reloading vscode or restarting your computer but this is still an annoying bug 😔
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?
Similar to what @Tyriar said, I was only able to finally run npm update
after I ran npm cache verify
ONLY if I closed VSCode before running npm update
(I'm on Windows 7).
@HaulinOats thank you so much for this, I was about ready to lose it.
@octogonz To change your typescript version follow these instructions
Is there a version that doesn't have this defect?
A temporary fix for this is to close your close your editor, then node_modules
will 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.
@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! :-)
Added a workaround to the top issue that's much better than reloading the window.
This puzzlement had been haunting my mind for a long time and not until this issue did I get its point! Until then, all I can do is restart the computer. :joy:
I don't have an option to restart the typescript server?
@biltongza the option shows up when you have a js/ts file open.
I don't have an option to restart the typescript server?
@biltongza you can restart your vscode
You can Reload Window
It's a serious regression that makes the VSCode+TypeScript user experience seem glitchy and not professional.
For reference, I've reproduced this today working with vanilla node (w/yarn rather than npm) when trying to delete node_modules
. I couldn't get inside the folder to confirm that @types
was the problem, but it did fix itself as soon as I closed VSCode.
(Fortunately Google was useful enough to get me here despite the somewhat misleading error message from Windows!)
Hey everyone, just to clarify: we intend to fix this bug in the TypeScript 3.5 milestone
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
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
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.
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 -xfd
which worked, so maybe this is triggered somehow after TS Server has been up for a while? 🤷♂
I faced the same issue, and closing the vscode helped me deleting the node_modules folder
Doesn't help that the issue is closed in both the TypeScript repo and the vscode repo, despite people still being directed here
Not sure if this is the same bug but I'm sure it's related. Sometimes checking out a branch fails halfway because VSCode has files open which leaves my working tree in an inbetween state and it's annoying to fix (git reset --hard
& git clean -fd
does the trick). I still experience the problem in 1.35. Closing VSCode makes the problem magically go away. It's getting to a point where I will preemptively close VSCode before I change branches sometimes, just in case I hit this issue again.
@sheetalkamat can we reopen this issue? It is clear that Electron 3.1.8 did not fix the issue (at least not completely).
This issue was for the TypeScript language service. You file lock might be from that, or it could be from any other plugin you're using, or it could also be from Electron itself as was the case above. It's important to determine which compenent is responsible first, to make sure you're reporting the issue in the right GitHub project, and give the maintainers something to investigate.
Anecdotally I can say that VS Code has been working great for me so far since the Election fix. (Fingers crossed!)
Same issue, behavior with Visual Studio 2019 (16.1.3) on windows 10, running npm script that calls rimraf on node_modules gives a permissions error on files in the types
folder of a babel package.
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:
[10:14:46] 'watch' errored after 645 ms
[10:14:46] Error: EPERM: operation not permitted, unlink 'D:\dev\Microsoft\vscode\extensions\configuration-editing\out\typings'error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Immediately after I restart TS server and ran yarn watch
again and it worked, here's the full output:
PS D:\dev\Microsoft\vscode> yarn watch
yarn run v1.10.1
$ gulp watch --max_old_space_size=4095
[10:14:31] Node flags detected: --max_old_space_size=4095
[10:14:31] Respawned to PID: 9544
[10:14:45] Using gulpfile D:\dev\Microsoft\vscode\gulpfile.js
[10:14:45] Starting 'watch'...
[10:14:45] Starting clean-out ...
[10:14:45] Starting clean-extension-configuration-editing ...
[10:14:45] Starting clean-extension-css-language-features-client ...
[10:14:45] Starting clean-extension-css-language-features-server ...
[10:14:45] Starting clean-extension-debug-auto-launch ...
[10:14:45] Starting clean-extension-debug-server-ready ...
[10:14:45] Starting clean-extension-emmet ...
[10:14:45] Starting clean-extension-extension-editing ...
[10:14:45] Starting clean-extension-git-ui ...
[10:14:45] Starting clean-extension-git ...
[10:14:45] Starting clean-extension-grunt ...
[10:14:45] Starting clean-extension-gulp ...
[10:14:45] Starting clean-extension-html-language-features-client ...
[10:14:45] Starting clean-extension-html-language-features-server ...
[10:14:45] Starting clean-extension-jake ...
[10:14:45] Starting clean-extension-json-language-features-client ...
[10:14:45] Starting clean-extension-json-language-features-server ...
[10:14:45] Starting clean-extension-markdown-language-features-preview-src ...
[10:14:45] Starting clean-extension-markdown-language-features ...
[10:14:45] Starting clean-extension-merge-conflict ...
[10:14:45] Starting clean-extension-npm ...
[10:14:45] Starting clean-extension-php-language-features ...
[10:14:45] Starting clean-extension-python ...
[10:14:45] Starting clean-extension-typescript-basics-test-colorize-fixtures ...
[10:14:45] Starting clean-extension-typescript-language-features ...
[10:14:45] Starting clean-extension-vscode-api-tests ...
[10:14:45] Starting clean-extension-vscode-colorize-tests ...
[10:14:45] Starting clean-extension-vscode-test-resolver ...
[10:14:45] Finished clean-extension-markdown-language-features-preview-src after 55 ms
[10:14:45] Starting watch-extension:markdown-language-features-preview-src ...
[10:14:45] Starting compilation...
[10:14:45] Finished clean-extension-typescript-basics-test-colorize-fixtures after 71 ms
[10:14:45] Starting watch-extension:typescript-basics-test-colorize-fixtures ...
[10:14:45] Finished clean-extension-css-language-features-server after 190 ms
[10:14:45] Starting watch-extension:css-language-features-server ...
[10:14:45] Finished clean-extension-emmet after 210 ms
[10:14:45] Starting watch-extension:emmet ...
[10:14:45] Finished clean-extension-html-language-features-client after 220 ms
[10:14:45] Starting watch-extension:html-language-features-client ...
[10:14:45] Finished clean-extension-html-language-features-server after 238 ms
[10:14:45] Starting watch-extension:html-language-features-server ...
[10:14:45] Finished clean-extension-merge-conflict after 227 ms
[10:14:45] Starting watch-extension:merge-conflict ...
[10:14:45] Finished clean-extension-extension-editing after 372 ms
[10:14:45] Starting watch-extension:extension-editing ...
[10:14:45] Finished clean-extension-grunt after 375 ms
[10:14:45] Starting watch-extension:grunt ...
[10:14:46] Starting watch-extension:gulp ...
[10:14:46] Finished clean-extension-jake after 394 ms
[10:14:46] Starting watch-extension:jake ...
[10:14:46] Finished clean-extension-json-language-features-server after 410 ms
[10:14:46] Starting watch-extension:json-language-features-server ...
[10:14:46] Finished clean-extension-npm after 425 ms
[10:14:46] Starting watch-extension:npm ...
[10:14:46] Finished clean-extension-vscode-test-resolver after 389 ms
[10:14:46] Starting watch-extension:vscode-test-resolver ...
[10:14:46] Finished clean-extension-vscode-colorize-tests after 404 ms
[10:14:46] Starting watch-extension:vscode-colorize-tests ...
[10:14:46] 'watch' errored after 645 ms
[10:14:46] Error: EPERM: operation not permitted, unlink 'D:\dev\Microsoft\vscode\extensions\configuration-editing\out\typings'error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
PS D:\dev\Microsoft\vscode> yarn watch
yarn run v1.10.1
$ gulp watch --max_old_space_size=4095
[10:15:32] Node flags detected: --max_old_space_size=4095
[10:15:32] Respawned to PID: 12856
[10:15:47] Using gulpfile D:\dev\Microsoft\vscode\gulpfile.js
[10:15:47] Starting 'watch'...
[10:15:47] Starting clean-out ...
[10:15:47] Starting clean-extension-configuration-editing ...
[10:15:47] Starting clean-extension-css-language-features-client ...
[10:15:47] Starting clean-extension-css-language-features-server ...
[10:15:47] Starting clean-extension-debug-auto-launch ...
[10:15:47] Starting clean-extension-debug-server-ready ...
[10:15:47] Starting clean-extension-emmet ...
[10:15:47] Starting clean-extension-extension-editing ...
[10:15:47] Starting clean-extension-git-ui ...
[10:15:47] Starting clean-extension-git ...
[10:15:47] Starting clean-extension-grunt ...
[10:15:47] Starting clean-extension-gulp ...
[10:15:47] Starting clean-extension-html-language-features-client ...
[10:15:47] Starting clean-extension-html-language-features-server ...
[10:15:47] Starting clean-extension-jake ...
[10:15:47] Starting clean-extension-json-language-features-client ...
[10:15:47] Starting clean-extension-json-language-features-server ...
[10:15:47] Starting clean-extension-markdown-language-features-preview-src ...
[10:15:47] Starting clean-extension-markdown-language-features ...
[10:15:47] Starting clean-extension-merge-conflict ...
[10:15:47] Starting clean-extension-npm ...
[10:15:47] Starting clean-extension-php-language-features ...
[10:15:47] Starting clean-extension-python ...
[10:15:47] Starting clean-extension-typescript-basics-test-colorize-fixtures ...
[10:15:47] Starting clean-extension-typescript-language-features ...
[10:15:47] Starting clean-extension-vscode-api-tests ...
[10:15:47] Starting clean-extension-vscode-colorize-tests ...
[10:15:47] Starting clean-extension-vscode-test-resolver ...
[10:15:47] Finished clean-extension-markdown-language-features-preview-src after 46 ms
[10:15:47] Starting watch-extension:markdown-language-features-preview-src ...
[10:15:47] Starting compilation...
[10:15:47] Finished clean-extension-typescript-basics-test-colorize-fixtures after 106 ms
[10:15:47] Starting watch-extension:typescript-basics-test-colorize-fixtures ...
[10:15:47] Finished clean-extension-css-language-features-client after 191 ms
[10:15:47] Starting watch-extension:css-language-features-client ...
[10:15:47] Finished clean-out after 236 ms
[10:15:47] Starting watch-client ...
[10:15:50] Finished clean-extension-css-language-features-server after 3265 ms
[10:15:50] Starting watch-extension:css-language-features-server ...
[10:15:50] Finished clean-extension-debug-auto-launch after 3285 ms
[10:15:50] Starting watch-extension:debug-auto-launch ...
[10:15:50] Finished clean-extension-debug-server-ready after 3303 ms
[10:15:50] Starting watch-extension:debug-server-ready ...
[10:15:50] Finished clean-extension-emmet after 3320 ms
[10:15:50] Starting watch-extension:emmet ...
[10:15:50] Finished clean-extension-extension-editing after 3344 ms
[10:15:50] Starting watch-extension:extension-editing ...
[10:15:50] Finished clean-extension-git after 3341 ms
[10:15:50] Starting watch-extension:git ...
[10:15:50] Finished clean-extension-git-ui after 3358 ms
[10:15:50] Starting watch-extension:git-ui ...
[10:15:50] Finished clean-extension-html-language-features-client after 3371 ms
[10:15:50] Starting watch-extension:html-language-features-client ...
[10:15:50] Finished clean-extension-json-language-features-client after 3356 ms
[10:15:50] Starting watch-extension:json-language-features-client ...
[10:15:50] Finished clean-extension-json-language-features-server after 3387 ms
[10:15:50] Starting watch-extension:json-language-features-server ...
[10:15:51] Finished clean-extension-markdown-language-features after 3433 ms
[10:15:51] Starting watch-extension:markdown-language-features ...
[10:15:51] Finished clean-extension-merge-conflict after 3448 ms
[10:15:51] Starting watch-extension:merge-conflict ...
[10:15:51] Finished clean-extension-npm after 3467 ms
[10:15:51] Starting watch-extension:npm ...
[10:15:51] Finished clean-extension-php-language-features after 3498 ms
[10:15:51] Starting watch-extension:php-language-features ...
[10:15:51] Finished clean-extension-python after 3515 ms
[10:15:51] Starting watch-extension:python ...
[10:15:51] Finished clean-extension-typescript-language-features after 3522 ms
[10:15:51] Starting watch-extension:typescript-language-features ...
[10:15:51] Finished clean-extension-configuration-editing after 3882 ms
[10:15:51] Starting watch-extension:configuration-editing ...
[10:15:51] Finished clean-extension-grunt after 3874 ms
[10:15:51] Starting watch-extension:grunt ...
[10:15:51] Finished clean-extension-gulp after 3888 ms
[10:15:51] Starting watch-extension:gulp ...
[10:15:51] Finished clean-extension-html-language-features-server after 3900 ms
[10:15:51] Starting watch-extension:html-language-features-server ...
[10:15:51] Finished clean-extension-jake after 3918 ms
[10:15:51] Starting watch-extension:jake ...
[10:15:51] Finished clean-extension-vscode-api-tests after 3891 ms
[10:15:51] Starting watch-extension:vscode-api-tests ...
[10:15:51] Finished clean-extension-vscode-colorize-tests after 3902 ms
[10:15:51] Starting watch-extension:vscode-colorize-tests ...
[10:15:51] Finished clean-extension-vscode-test-resolver after 3901 ms
[10:15:51] Starting watch-extension:vscode-test-resolver ...
[10:19:19] Finished compilation with 0 errors after 212194 ms
See https://github.com/microsoft/TypeScript/issues/32113 which sounds like it is not VS Code (electron) specific
See #32113 which sounds like it is not VS Code (electron) specific
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.
What version do I need to upgrade to in order to fix this?
What version do I need to upgrade to in order to fix this?
You don't
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.
@JohnGalt1717 This is an already closed issue pertaining to the TypeScript compiler service (and which turned out to be an Electron bug, not TypeScript). The errors definitely stopped happening for me after the fix, so I'm somewhat skeptical that TypeScript is the cause of your issue. Are you sure it's not caused by something else like one of your VSCode extensions, or your virus scanner, etc? Your issue is more likely to get fixed if you report it to the right GitHub project.
safe mode with 0 extensions still causes it. I tried and they referred to this issue and closed it.
I'm definitely still seeing this, both in VS Code and VS Pro, so it's not VS Code-specific. Since restarting TS Server helps, the issue looks like it should be in this repo.
It's probably best to continue discussion in the open dupe issue https://github.com/microsoft/TypeScript/issues/32113. They need reliable repro steps.
this STILL happens with TS 3.7.2 and VSCODE 1.40.1
I also experience similar issues, ever since I started using VS Code, now I am on the version 1.41. It prevents me to delete folders inside the project dir. Distracts git, sometimes even fetch fails, while VS Code is running.
Yes, I have this issue while using VSCode with projects, especially those involving javascript files.
@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?
@biltongza they're way too busy handling real issues with VScode like the santa hat on the settings cog
This still exists as of August 2021. I'm having the same error messages as @nharrer and this is a major annoyance.
This issue was not resolved for me, I am not using node, typescript, or windows. Just posting here since all other similar issues where closed with reference to 'upstream' i.e. this one. Running into it with a potential combination of other issues. See here: https://github.com/Azure/azure-functions-python-worker/issues/1306#issuecomment-1691391077.
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:
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(R) Core(TM) i5-4670K CPU @ 3.40GHz (4 x 3398)| |GPU Status|2d_canvas: enabledchecker_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)