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

SimmeNilsson commented 4 weeks ago

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

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

sheremet-va commented 4 weeks ago

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[bot] commented 4 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

Output

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

SimmeNilsson commented 3 weeks ago

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 commented 3 weeks ago

[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.

vitest-dev / vscode