What problem does this address?

The TypeScript type-checking and declaration generation step (tsc --build) is one of the slowest parts of the Gutenberg build pipeline. With ~84 packages using project references, full type builds take significant time, slowing down CI and local development.

TypeScript 7 introduces tsgo, a native Go-based compiler (@typescript/native-preview) that offers ~10x faster type-checking and builds. Adopting it would dramatically reduce build times.

What is your proposed solution?

Replace tsc with tsgo for type-checking and declaration generation across the build pipeline.

Blockers

1. esModuleInterop: false removed in TypeScript 7

tsconfig.base.json sets "esModuleInterop": false. TypeScript 7 has removed support for this option being set to false (TS5108). This affects every package that inherits from the base config.

2. JSDoc @typedef with @template generates broken declarations

tsgo drops generic type parameters from JSDoc @typedef declarations that use @template. For example:

/**
 * @typedef {import('./types').StoreDescriptor<C>} StoreDescriptor
 * @template {import('./types').AnyConfig} C
 */

generates a non-generic alias in the .d.ts:

export type StoreDescriptor = import('./types').StoreDescriptor< C >; // C is unresolved

This appears to be a bug in tsgo's declaration emit for JSDoc — no upstream issue has been filed yet. The workaround is to replace @typedef aliases with inline import() type references in JSDoc @template/@param/@return tags. This pattern is used extensively in packages/data.

3. packages/data is not fully/properly typed

Most downstream type errors originate from packages/data not being fully typed. The package is implemented in JavaScript with JSDoc annotations, and several of its public APIs (useSelect, useDispatch, createReduxStore) rely on the broken @typedef+@template pattern described above. When these generate incorrect declarations, every consumer that calls select(store).someSelector() loses type information, causing a cascade of TS2339 (property does not exist) and TS7006 (implicit any) errors across the codebase. Same applies to the core-data package. So, we should probably convert them to TypeScript before attempting the migration.

Fully typing or converting packages/data to TypeScript would resolve the majority of the migration errors.

4. skipLibCheck does not suppress parse errors in node_modules

tsgo's skipLibCheck: true does not suppress TS1540 errors ("module keyword should be namespace") from third-party .d.ts files (lighthouse, wasm-vips). These are parse-level errors that bypass the skip. This needs to be fixed upstream in tsgo or in those packages.

5. Unused @ts-expect-error directives

tsgo resolves some type errors that tsc could not, causing ~43 @ts-expect-error directives to become unnecessary (TS2578). These are straightforward to remove.

6. Stricter type checking in various packages

tsgo is stricter than tsc 5.x in several areas:

• CSS/SCSS side-effect imports require ambient module declarations (TS2882)
• Index signature mismatches on string-keyed object access (TS7053)
• Declaration emit "cannot be named" errors for unexported types (TS4023, TS4058)
• Stricter conditional type resolution and type narrowing

Analysis by Claude Code