Build: Fix ESM declaration resolution

[ciampo]

Closes #80206
Supersedes #80606

What?

Fixes the published TypeScript declarations for the four ESM packages that emitted extensionless relative specifiers:

• @wordpress/design-system-mcp
• @wordpress/theme
• @wordpress/video-conversion
• @wordpress/vips

It also adds final-package validation for current and future published ESM packages.

Why?

TypeScript preserves source import specifiers in declaration output. Extensionless specifiers work with moduleResolution: "bundler", but they fail Node-style ESM resolution.

Declaration files are exempt from TypeScript's allowImportingTsExtensions restriction. A published declaration can therefore import ./types.ts, resolve it to types.d.ts under Node16 or NodeNext, and work without that flag in the consumer project.

TypeScript 4.x rejects these explicit source extensions in declaration files. This change therefore establishes TypeScript 5 as the minimum for TypeScript consumers of the four affected packages, and their changelogs classify the change as breaking.

How?

The affected production sources now use explicit .ts and .tsx relative specifiers, and their declaration-build projects enable allowImportingTsExtensions. The runtime build continues to convert these specifiers to .mjs.

After the production build, the declaration check packs each public ESM package once. For packages that publish declarations, it mirrors only the packed files into an isolated package tree and checks those declarations under NodeNext with the repository TypeScript compiler. It reuses the same archive for @arethetypeswrong/cli checks under Node16 ESM and bundler resolution. CSS-only exports are excluded because TypeScript cannot resolve CSS assets.

Testing Instructions

1. Run npm run test:unit tools/build-scripts/test/check-esm-package-types.test.js.
2. Run npm run typecheck.
3. Run npm run build.
4. Run npm run check:type-declarations.
5. Confirm that NodeNext passes and the packed-package tables are green for Node16 ESM and bundler resolution for all four packages.

Testing Instructions for Keyboard

Not applicable. This PR does not change the UI.

Use of AI Tools

Codex was used to implement the changes, run verification, and draft this PR description.

[github-actions]

Size Change: 0 B

Total Size: 7.91 MB

_{compressed-size-action}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: i-am-chitti <iamchitti@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 193c6bc.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/32959355605
📝 Reported tests:

should be disabled when post is being saved in /test/e2e/specs/editor/various/publish-button.spec.js, passed after 1 failed attempt.

Error: expect(locator).toBeDisabled() failed

Locator:  getByRole('region', { name: 'Editor top bar' }).getByRole('button', { name: 'Publish' })
Expected: disabled
Received: enabled
Timeout:  5000ms

Call log:
  - Expect "toBeDisabled" with timeout 5000ms
  - waiting for getByRole('region', { name: 'Editor top bar' }).getByRole('button', { name: 'Publish' })
    14 × locator resolved to <button type="button" aria-disabled="false" aria-expanded="false" class="components-button editor-post-publish-panel__toggle editor-post-publish-button__button is-primary is-compact">Publish</button>
       - unexpected value "enabled"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/publish-button.spec.js:62:5

[manzoorwanijk]

Two minor things. Looks good otherwise.

[ciampo]

@manzoorwanijk before merging, just double-checking: do we have any policies areound min supported TS version? The changes from this PR will cause errors on TS < 5 . I assumed it's fine, since latest version is 7, and version 5 was introduced in 2023 — but wanted to double-check

[manzoorwanijk]

We don’t have any such policy and it should be fine.

[aduth]

If we're adding all these extensions, should we also update the package's TypeScript configs to specify "moduleResolution": "nodenext" instead of "moduleResolution": "bundler"? IIRC the primary reason for using "bundler" is for the extensionless imports. And presumably we'd want the restrictiveness to avoid extensionless imports being added in the future?

'bundler' for use with bundlers. Like node16 and nodenext, this mode supports package.json "imports" and "exports", but unlike the Node.js resolution modes, bundler never requires file extensions on relative paths in imports.

https://www.typescriptlang.org/tsconfig/#moduleResolution

[ciampo]

Good point, opened #82088 to address