TypeScript: Bring the remaining route projects under the typecheck run

[manzoorwanijk]

What?

Follow up to #81829. See #81473. Adds a tsconfig.json to the 23 remaining route projects and registers them (plus a test project for routes/connectors-home) in the root tsconfig.json, so npm run typecheck checks every route.

Why?

These routes have TypeScript files that no project covered, so their type errors never surfaced. Putting them under the check exposed 48 real errors, fixed here.

How?

Each route tsconfig.json mirrors the #81829 shape, with references derived from its package.json. The validator now also fails when a route has TypeScript files but no tsconfig.json (2 new tests). @wordpress/block-library joins the untyped-package paths mapping, since its import resolves to built JS that checkJs would sweep in. The exposed errors are fixed with annotations, the established inline-generic pattern for entity records, narrowing, and casts where selector types fall short. ConfirmDialog types its existing __experimentalHideHeader passthrough; @wordpress/media-editor exports its existing frame/save-result types.

Testing Instructions

1. npm run typecheck passes.
2. Add const bad: number = 'x'; to routes/home/route.ts and rerun: it fails.
3. npm run lint:tsconfig passes; delete routes/home/tsconfig.json and it fails.

Use of AI Tools

Written with the help of an AI assistant, reviewed and edited by the author.

[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: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@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]

Size Change: +21 B (0%)

Total Size: 7.78 MB

📦 View Changed

Filename	Size	Change
build/scripts/components/index.min.js	264 kB	+21 B (+0.01%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 40c0f24.
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/32480480936
📝 Reported tests:

Should save the changes in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js, passed after 2 failed attempts.

TimeoutError: page.waitForFunction: Timeout 10000ms exceeded.
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js:34:14
TimeoutError: locator.click: Timeout 10000ms exceeded.
Call log:
  - waiting for locator('role=button[name="Visual"i]')

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js:33:55

[andrewserong]

This is looking good to me, thanks again for the work here, it'll be a big help for those of us chipping away at various different routes 👍

Left a couple of tiny nit-picky comments, but nothing blocking. And I smoke-tested each of the routes that they're loading correctly in my local env after a fresh npm install and build. The only bugs I encountered while testing out experimental routes were already present in trunk.

LGTM! 🚀

[andrewserong]

TIL that TS config JSON files don't mind code comments! Just double-checking, though, tsc doesn't mind that this code comment is here, but do we have anything else that minds that this isn't (purely) valid JSON.

I assume it's fine since all the Github actions are passing, and the build succeeds locally.

[manzoorwanijk]

Yes, tsconfig have always supported comments.

[andrewserong]

Why is this needed, it looks like editEntityRecord is described as supporting undefined for recordId, so I wasn't sure why we need the double as here. Apologies if I'm missing something obvious!

gutenberg/packages/core-data/src/actions.js

Line 433 in 0619247

* @param {number|string|undefined} recordId Pass `undefined` for keyless entities.

[manzoorwanijk]

There is apparently some issue with TS inferring types from JSDoc. I am planning to look into it as a follow up.

[andrewserong]

Similar comment as the other one I mentioned: can this just be a plain const siteRecordKey = undefined or does it need the "as" here?