Support deferred re-exports #64602

🔍 Search Terms

export defer, deferred re-exports, deferred re-exports, lazy barrel files

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Support the TC39 Deferred Re-exports proposal, which is now at Stage 2.7, including named and namespace re-exports:

export defer { a } from "./a.js";
export defer * as b from "./b.js";

Preserve the syntax in supported JavaScript output and declaration files, while retaining the types of exported bindings.

📃 Motivating Example

// a.ts
export function a(c: number, d: number): number {
    return c + d;
}

// b.ts
export function b(c: number, d: number): number {
    return c - d;
}

// c.ts
export defer { a } from "./a.js";
export defer { b } from "./b.js";

// d.ts
import { a } from "./c.js";

const b: number = a(1, 2);

Importing a does not require loading the unused module b.ts.

💻 Use Cases

1. What do you want to use this for?
   Provide a shared entry point without loading unused modules
2. What shortcomings exist with current approaches?
   Ordinary static re-exports load unused dependencies in native ESM.
3. What workarounds are you using in the meantime?
   Alternatives are direct module imports or dynamic import().