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

fsModuleCache caches a module whose `import.meta.glob` call has a type argument

Closed Beginner friendly
  • Is something wrong?
#11,633 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #11650 by @chiragjangiir — closed without merging
  • #11666 by @sheremet-va — merged

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript, vite
Domain
build-system, testing

Research direction

Start at FileSystemModuleCache.generateCachePath and locate its existing cache-key tests. Run the supplied Vitest reproduction with experimental.fsModuleCache, then update the import.meta.glob detection so a generic type argument prevents caching; done means the new-file reproduction passes and existing detection cases remain green.

Written by the indexing model from the issue text.

Description

Describe the bug

With experimental.fsModuleCache, FileSystemModuleCache.generateCachePath skips a module that uses import.meta.glob by checking fileContent.includes("import.meta.glob("). A call with a TypeScript type argument, which Vite's own types document, doesn't contain that text:

const modules = import.meta.glob<Record<string, unknown>>("./src/*.ts", { eager: true });

So the module is cached with the glob already expanded into one import per file that matched at the time. A later run whose tree holds different files reuses that transform, because the key hashes the module's own source and not the glob's matches:

  • A file added since is missing from the glob's result.
  • A file removed since, for example after a branch switch, fails with a failed import of the file that is gone.

We hit the second on CI runners that keep the cache between jobs: one branch's extra file broke the same test on every other branch.

Reproduction
src/a.js        export default 1;
src/b.js        export default 2;
glob.test.ts    import { expect, test } from "vitest";
                const files = import.meta.glob<unknown>("./src/*.js", { eager: true });
                test("glob", () => expect(Object.keys(files)).toHaveLength(Number(process.env.EXPECTED)));
vitest.config.mts
                export default { test: { experimental: { fsModuleCache: true } } };
  1. EXPECTED=2 vitest run passes and writes the cache.
  2. Add src/c.js.
  3. EXPECTED=3 vitest run fails: expected [ './src/a.js', './src/b.js' ] to have a length of 3 but got 2.

Without the type argument, step 3 passes.

Expected

Step 3 passes. Matching import.meta.glob followed by optional whitespace and < or (, or plain import.meta.glob, would cover it. The second form also catches a call split over lines.

Workaround

A plugin that registers a cache key generator returning false for such modules:

{
    name: "module-cache-globs",
    configureVitest({ experimental_defineCacheKeyGenerator }) {
        experimental_defineCacheKeyGenerator(({ sourceCode }) =>
            sourceCode.includes("import.meta.glob") ? false : "",
        );
    },
}
System info

vitest 4.1.11, and the same check is in 5.0.5's cli-api chunk. Vite 8, Node 24.21.0, macOS, default forks pool.

Related: #11575, which covers other inputs the key misses.

Dominant language
TypeScript
Stars
17.3k
Forks
2.1k
Avg merge
20h 59m
Merged PRs (30d)
163

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 vitest-dev/vitest

All issues in vitest-dev/vitest

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.