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

[SimmeNilsson]

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

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