vitest plugin keeps a file lock on rollup and esbuild which halts package upgrades at times

[SimmeNilsson]

Describe the bug

When I upgrade my npm packages using yarn 1.x I every now and then get
error Error: EPERM: operation not permitted, unlink '...\node_modules@esbuild\win32-x64\esbuild.exe'
or
error Error: EPERM: operation not permitted, unlink '...\node_modules@rollup\rollup-win32-x64-msvc\rollup.win32-x64-msvc.node'

The locking process belongs to the vitest VS Code plugin.
I am not running any tests at the time.

Reproduction

Usually happens when I upgrade npm packages.
Specifically when yarn tries to unlink either esbuild or rollup.
For reproduction example and instructions see this repo:
https://github.com/SimmeNilsson/FileLockVitestPlugin

Output

[INFO 4:09:05 PM] [v0.12.3] Vitest extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 4:09:09 PM] [API] Running Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 4:09:20 PM] [API] Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) process 59084 created
[INFO 4:09:23 PM] [API] Collecting tests: test/App.spec.ts

Version

0.12.3

Validations

• Check that you are using the latest version of the extension
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

I cannot reproduce this behavior. If package.json is updated, Vitest will close the running process and start a new one - maybe something happens during this?

None from vitest itself.

The output channel will contain at least the version, so if you don't see anything there, then you don't have the extension installed. Did you actually check it?

[github-actions]

Hello @SimmeNilsson. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[SimmeNilsson]

I've updated my initial description with output and reproduction repo.

Steps described in the README of the repo.
I think this approach should be pretty reliable.
Basically one needs to trigger an upgrade/downgrade of either rollup or esbuild (after making sure the plugin has been exercised) to see the issue.

As for the output, it is not when I exercise the test that I have the problem.
When running it is just normal output.
It is when I perform my package upgrade and yarn tries to unlink rollup and/or esbuild that I get the problem.
That was why I wrote like I initially did.

Edit: The file locking process in my last repro was
"C:\Program Files\nodejs\node.EXE" --dns-result-order=ipv4first C:/Users/.../.vscode/extensions/vitest.explorer-0.12.3/dist/worker.js

[sheremet-va]

Output

Is this the full output at the moment of getting an error? Did you remove anything from it?

[SimmeNilsson]

It is the full output.

As the tests run fine, should we expect anything more?
The problem I have is the file locks it seems to be keeping around rollup and esbuild when it isn't actively running tests.

The only error output I have is the one I get from yarn regarding the EPERM.
And when I track down the process responsible for holding the file (through Process Explorer), that process belongs to the plugin as far as I can tell (CLI line in last post).

[SimmeNilsson]

[INFO 4:34:20 PM] [v0.12.3] Vitest extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 4:34:22 PM] [API] Running Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 4:34:23 PM] [API] Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) process 66220 created
[INFO 4:34:25 PM] [API] Collecting tests: test/App.spec.ts
[INFO 4:36:01 PM] Running 1 file(s) with name pattern: ^\s?App math adds up$
[Worker] Collecting tests due to file changes: package.jso
[INFO 4:36:28 PM] [API] Vitest process 66220 closed successfully
[INFO 4:36:28 PM] [API] Running Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) with Node.js: C:\Program Files\nodejs\node.EXE
[INFO 4:36:29 PM] [API] Vitest v1.6.0 (FileLockVitestPlugin/vitest.config.mts) process 76060 created

I think I understand what you meant now.
That it restarts when package.json changes. However, within one second a new process is created.
If the unlinking of esbuild/rollup doesn't happen within that window, then a lock will be present (at least it seems to be for me).

In the two scenarios I've provided that window is either missed (A) or not present at all (B).

Scenario A
I manually add a resolution (can't be done through the yarn 1.x CLI AFAIK) to package.json.
Plugin process is automatically restarted.
Then I run yarn (install) to have package.json change reflected in node_modules and yarn.lock.

Scenario B
I delete the lock file and run yarn to recreate it, which might result in an upgrade of installed (within ranges given in package.json) esbuild or rollup.
package.json never touched.

Edit: Scenario C
Branch switch then yarn (install) to sync node_modules.

[SimmeNilsson]

Any luck in reproducing given the scenarios detailed above?

[MetRonnie]

I get this when switching between branches that have different versions of esbuild or rollup in yarn.lock. Deactivating the extension and clicking "restart extensions" allows yarn install to work. Reactivating the extension (even without running any tests) causes the EPERM error again when doing yarn install again

[sheremet-va]

I get this when switching between branches that have different versions of esbuild or rollup in yarn.lock. Deactivating the extension and clicking "restart extensions" allows yarn install to work. Reactivating the extension (even without running any tests) causes the EPERM error again when doing yarn install again

Do you use Windows?

[MetRonnie]

Yes

[ocombe]

Oh I keep getting that one and I was wondering where it was coming from. So annoying, I have to manually delete the node modules before rebuilding my code...

[sheremet-va]

Does this happen only with yarn 1? Are there any other instances of this happening with other package managers?

[MetRonnie]

Yarn 4.4.1 here

[sheremet-va]

So, the issue here is that the Vitest extension constantly maintains Vitest running in the background for an instant response. This typically functions well as package managers generally do not delete everything from the node_modules, but it seems yarn operates differently. I have a few suggestions to offer:

1. Add a command to stop the Vitest extension. You can run it before updating dependencies.
2. Add an option to use an old-fashioned Vitest extension that would spawn a new Vitest instance every time you click on a test. The tests will take longer to run in this case (debug already works like this, for example).