voidzero-dev / voidzero-dev/vite-plus
perf(migrate): Vitest signal detection repeatedly traverses package source trees
- Dominant language
- Rust
- Stars
- 5.8k
- Forks
- 261
- Avg merge
- 1d 34m
- Merged PRs (30d)
- 135
Description
### Summary
During the full project rewrite path of `vp migrate`, the same package source tree is traversed synchronously multiple times to collect Vitest browser/provider signals.
Under the following full-miss conditions:
- the source contains no relevant Vitest browser/provider references;
- no tsconfig contains Vitest types that must be retained;
- package.json contains no webdriverio/provider dependency that causes an early return;
the Vitest signal-detection phase reads every eligible TS/JS file through Node.js `fs.readFileSync`:
- 5 times for a standalone project;
- 9 times for each workspace package in a monorepo.
These counts cover only the JavaScript-side Vitest signal scans. They do not represent all file I/O performed during migration. For example, the later Rust/NAPI import rewriter also traverses and reads source files, but those reads are not visible to an `fs.readFileSync` probe.
### Local reproduction
I created temporary test projects containing many small `.ts` files with no Vitest browser/provider references. Their package.json files also contained no dependencies that would cause the checks to return early.
I then monitored `fs.readFileSync` calls for those fixture source files and invoked the production migration entry points directly.
| Call path | Source files | Source reads through `fs.readFileSync` | Duration |
| --- | ---: | ---: | ---: |
| `rewriteStandaloneProject` | 5,000 | 25,000 | 486 ms |
| `rewriteMonorepo` (2 × 2,500 files) | 5,000 | 45,000 | 734 ms |
Environment: macOS, Node.js 25.9.0, with the filesystem cache pre-warmed.
The per-file read counts are deterministic: exactly 5 reads per file for the standalone project and exactly 9 reads per file for each monorepo workspace package. Every detection result was `false`, so each check took its complete miss path.
The timings are included only to illustrate the approximate impact and will vary between machines.
### Observed call paths
`sourceTreeMatches` recursively traverses directories with `readdirSync` and reads every TS/JS file with an eligible extension using `readFileSync`. It returns early only after finding a match, so a complete miss is the worst-case path.
#### Standalone
Within a single `rewriteStandaloneProject` call:
1. `collectProviderSourceModes` scans once for each of the two current opt-in providers: 2 passes;
2. `usesVitestBrowserMode` performs another scan: 1 pass;
3. `sourceTreeReferencesRetainedVitestModule` scans the source again: 1 pass;
4. when no webdriverio dependency causes a short circuit, `usesWebdriverioProvider` performs another scan: 1 pass.
This results in 5 reads per source file.
`providerSourceModes` already contains the webdriverio source-detection result, but the standalone path subsequently calls `usesWebdriverioProvider` anyway.
In addition, `sourceTreeReferencesRetainedVitestModule` first performs a separate recursive directory traversal to discover tsconfig files and reads any matching tsconfig files it finds. As a result, the package directory tree is traversed 6 times on a complete standalone miss, with 5 of those passes reading TS/JS source files.
#### Monorepo workspace package
`rewriteMonorepo` first computes workspace-level signals. For every workspace package on the complete miss path:
- `workspaceUsesWebdriverio`: 1 source scan;
- `workspaceUsesVitestDirectly`:
- retained Vitest module: 1 scan;
- browser mode: 1 scan;
- `collectInjectedProviderNames`:
- two provider scans: 2 scans.
The workspace phase therefore reads each source file 5 times.
The same package is then processed by `rewriteMonorepoProject`, which recomputes:
- browser mode: 1 scan;
- retained Vitest module: 1 scan;
- source modes for two providers: 2 scans.
The package phase adds another 4 reads, for a total of 9 reads per source file in each workspace package.
The monorepo root package is not subsequently passed through `rewriteMonorepoProject`, so source files belonging directly to the root package are generally read 5 times rather than 9.
The two retained-module checks also each add a separate directory-tree traversal for locating tsconfig files. A workspace package therefore undergoes 11 related full directory-tree traversals on the complete miss path, 9 of which read TS/JS source files.
### Reusing scan results
In the reproduction projects above, no source files were modified between these scans in a way that could affect the results.
In the general monorepo path, however, `rewriteMonorepoProject` performs configuration merging before the package-level scans. That step may create or modify `vite.config.ts`. Reusing results between the workspace and package phases would therefore require confirming that these configuration changes cannot affect the relevant signals, or retaining the two phases while consolidating the scans performed within each phase.
Regardless of whether results can be cached across phases, each individual phase currently performs separate full traversals for several closely related boolean signals.
### Impact
The complete miss path remains linear in the number of files, but it has a fixed synchronous I/O amplification:
- standalone package: 5 reads per eligible source file;
- monorepo workspace package: 9 reads per eligible source file.
These directory traversals and file reads are synchronous and directly block `vp migrate`. The cost becomes noticeable in projects containing thousands or tens of thousands of source files.
Ideally, browser mode, retained Vitest module references, and provider signals could be collected during a single source-tree traversal, with the resulting scan data shared by callers within the same migration phase.
Contributor guide
Research direction
Start at rewriteStandaloneProject, rewriteMonorepo, and rewriteMonorepoProject, then trace sourceTreeMatches, collectProviderSourceModes, usesVitestBrowserMode, sourceTreeReferencesRetainedVitestModule, and usesWebdriverioProvider. Compare the workspace and package phases, including configuration merging, and consolidate compatible signal collection within each phase without changing early-return behavior. Done means the complete-miss paths avoid redundant source-tree reads while preserving all detection results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js, typescript
- Domain
- cli, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100