Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Test memo: record the Vitest setup/environment modules instead of hashing their 179-file static closure

Open
  • Is something wrong?
#12,298 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@atomantic is already working on this.

Since Oct 19, 2026.

Assessment

This issue has not been assessed yet.

Description

effort:high enhancement in-progress model:heavy plan tests

Problem

Every test memo key (scripts/lib/testMemo.js, WORKSPACE_BASE_INPUTS) includes the static closure of the workspace Vitest config, its setup files and the custom environment (server/test/mediaRegistryEnvironment.js). That closure is 179 files for the server workspace: the environment and vitest.setup.js pull in server/lib/mockPathsDataRoot.js, server/lib/fileWriteQueue.js, server/test/admissionSetup.js and what those import. A change anywhere in it invalidates all 3,095 server keys, although the setup phase loads only part of that graph at runtime. Vitest's recordDependencies depfile records globalSetup dependencies but not environment or setupFiles dependencies, so the memo has nothing better than the static walk today.

Measured on the last 12 merges on main (PR #12295): 11 merges invalidate 7–828 recorded keys each; the environment closure is the remaining whole-suite trigger.

Chosen approach

Record what the setup phase actually loads, the same way test files are recorded, and use that for the recorded key:

  1. Register a small custom reporter in both workspace configs (scripts/vitestSetupDependencies.js). In onTestRunEnd it reads each project's module graph (project.vite.environments.__vitest__.moduleGraph) for the setupFiles and environment entries, collects the transitive imported modules that are local source files, and writes <cacheDir>/vitest/setup-dependencies.json (root-relative paths, same shape as dependencies.json modules).
  2. scripts/lib/testMemoRunner.js reads that file next to dependencies.json; createTestMemoAnalyzer.workspaceBase accepts a recorded module list and, when present, the recorded key uses it in place of the static base closure. The floor key keeps the static walk.
  3. scripts/lib/testMemo.test.js pins that a change to a module the setup phase never loaded leaves the recorded key unchanged, and that a change to one it did load moves it.

Acceptance

  • The server base input set for the recorded key drops from 179 files to the modules the setup phase loads (expected well under 60).
  • A change to a leaf under server/lib/ that neither the setup phase nor a given test loads leaves that test's recorded key unchanged.
  • Floor-key behavior is unchanged.
Dominant language
JavaScript
Stars
38
Forks
32
Avg merge
33m
Merged PRs (30d)
988

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from atomantic/PortOS

All issues in atomantic/PortOS

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.