Turbopack: accept a module type argument for import.meta.glob

[kelvinampofo]

What?

Adds support for passing a module type to the TypeScript overloads for import.meta.glob:

const entries = import.meta.glob<Entry>("./entries/*.ts");

This works with both lazy and eager imports. If a module type isn’t provided, it defaults to unknown, which matches the current behavior.

Why?

Next.js already supports Vite’s import.meta.glob API at runtime, but its TypeScript declarations don’t support Vite’s module generic.

Because of this, a typed glob works in Vite but fails in Next.js:

TS2558: Expected 0 type arguments, but got 1.

Consumers currently have to cast the result or add their own ImportMeta declaration to describe the matched modules. Supporting the generic removes the need for those workarounds and makes typed glob imports consistent between Next.js and Vite.

How?

Each existing overload now accepts a generic module type, M, which defaults to unknown:

• Lazy imports return Record<string, () => Promise<M>>.
• Eager imports return Record<string, M>.

Using unknown as the default means existing calls without a generic keep the same types as before.

I also updated the existing e2e fixture. It had an old local ImportMeta.glob declaration that returned Record<string, any>. Removing that declaration exposed the missing generic and allowed the five as any casts in the fixture to be removed. Without the generic, all five glob calls fail during next build with TS2558. With it, all five pass.

The Turbopack documentation has also been updated with examples showing how to use the generic with lazy and eager imports.

Checklist

• pnpm --filter=next types passes
• pnpm prettier-fix run
• Documentation follows the docs contribution guide
• E2E test passes