Repository navigation
[Bug]: Every test run leaves a temp folder behind (vitest 5.0.1 via vite-plus 1.0.0) #20128
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
Build, CI, or release tooling
Steps to reproduce
On a clean checkout of main:
pnpm install
T=$(mktemp -d)
cd packages/contracts && TMPDIR=$T pnpm run test
ls -A "$T"Expected behavior
A finished test run leaves nothing behind in the temp dir. The exception is node-compile-cache, which is reused across runs.
Actual behavior
Every run leaves a <tmpdir>/<21-char id>/ssr/ folder of transformed module copies, even when every test passes. For packages/contracts that's 109 files and 4.4 MB. apps/server runs leave up to ~34 MB each.
Cause: the catalog pins vite-plus 1.0.0, which pins vitest 5.0.1. In Vitest 5.0.0–5.0.2, Vitest.close() never removes the root _tmpDir that holds the forks pool's module copies. Vitest fixed this in 5.0.3: "Remove root temp dir on close" (vitest-dev/vitest#11248). vite-plus 1.1.0 ships vitest 5.0.3, and 1.2.0 ships 5.0.4.
Agents run tests in worktrees all day, so the folders pile up. On one machine, 411 of them (11.8 GB, uncompressed) came from t3code worktrees in under 3 days.
Suggested fix: bump the vite-plus and vite (@voidzero-dev/vite-plus-core) catalog entries to 1.2.0. I made the same bump in another repo on vite-plus 1.0.0: its 710 tests still passed and the run left no folder behind.
Impact
Minor bug or occasional failure
Version or commit
main @ e74f477
Environment
CachyOS Linux (kernel 7.2.10), Node 26.11.1, pnpm 11.10.0, vite-plus 1.0.0, vitest 5.0.1
Logs or stack traces
$ cd packages/contracts && TMPDIR=$T pnpm run test
RUN v5.0.1 …/packages/contracts
Test Files 39 passed (39)
Tests 667 passed (667)
$ ls -A "$T"
NEcLqKcMrzjuO4WeCz9m7
node-compile-cache
$ ls "$T/NEcLqKcMrzjuO4WeCz9m7"
ssr
$ ls "$T/NEcLqKcMrzjuO4WeCz9m7/ssr" | wc -l
109Workaround
Delete stale <id>/ssr folders from the temp dir by hand, or override vitest to 5.0.3 or later.
Activity
juliusmarminge commentedon Oct 16, 2026
Note
Grok responding on behalf of Julius.
Thanks for the clear repro. Confirmed on main: the
pnpm-workspace.yamlcatalog pinsvite-plus: 1.0.0andvite: npm:@voidzero-dev/vite-plus-core@1.0.0, and vite-plus 1.0.0 depends onvitest5.0.1.The root cause is upstream. Vitest 5.0.0–5.0.2 never removes its root temp dir on close, and 5.0.3 fixed that ("Remove root temp dir on close", vitest-dev/vitest#11248). Nothing in T3's test setup needs to change. The fix on our side is a dependency bump: on npm, vite-plus 1.1.0 depends on vitest 5.0.3 and 1.2.0 on vitest 5.0.4, each paired with the matching
@voidzero-dev/vite-plus-core.I'm keeping this open as a minor tooling chore to bump both catalog entries to 1.2.0. Until that lands, the workaround is to delete stale
<tmpdir>/<id>/ssrfolders.Lenoridev commentedon Oct 21, 2026
This can be closed as fixed on main by #22716, merged as
a1dc856ee6on October 21.I compared all changes in #21603 with main at
21da3061aa. The merged upgrade fully supersedes that PR:vite-plusand thevitealias for@voidzero-dev/vite-plus-coreare pinned to 1.3.0, beyond the proposed 1.2.0.@vitest/browser-playwrightis pinned to 5.0.5, matching the newer runner.I also checked the installed Vitest 5.0.5 source. Closing the runner awaits
_clearTmpDir(), which recursively removes its temporary directory.For execution evidence, I ran an isolated minimal test with these exact tooling versions on Linux x64 and Node 24.13.1. It imports another TypeScript module and uses the forks pool:
The test passed. After the process exited, the fresh temporary directory contained only
node-compile-cache, with no transformed-module folder. This was a focused runner check rather than a full repository test run.#21603 is closed as superseded. Its complete scope was the version pins and generated lockfile, so no additional change from it is needed for this issue.
t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. This is fixed on main in #22716. Please test on the nightly built from main on 2026-10-21, or on the next stable release. If the problem still occurs there, please open a new issue that links to this one, with your version and steps to reproduce it.