Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

perf(migrate): Vitest signal detection repeatedly traverses package source trees

Aperta
  • Qualcosa non va?
#2,420 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@m0g3r ci sta già lavorando.

Dal 23/8/2026.

  • #2541 di @m0g3r — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
58/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript, node.js, typescript
Ambito
cli, performance

Direzione di ricerca

Inizia da rewriteStandaloneProject, rewriteMonorepo e rewriteMonorepoProject, quindi segui sourceTreeMatches, collectProviderSourceModes, usesVitestBrowserMode, sourceTreeReferencesRetainedVitestModule e usesWebdriverioProvider. Confronta le fasi workspace e package, inclusa la fusione della configurazione, e consolida la raccolta dei segnali compatibili all'interno di ciascuna fase senza modificare il comportamento dei ritorni anticipati. Il lavoro è completo quando i percorsi di mancata corrispondenza completa evitano letture ridondanti dell'albero dei sorgenti preservando tutti i risultati del rilevamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
6k
Fork
274
Merge medio
1g 11h
PR unite (30g)
196

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-plus

Tutte le issue di voidzero-dev/vite-plus

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.