What?

Follow up to #78882 (discussion).

Fixes every remaining case where a package's published artifact — its runtime JS or emitted build-types/*.d.ts — references a module that consumers installing from npm cannot resolve, as surfaced by auditing all packages with @mawesome/dependency-audit (wired into the repo as npm run lint:published-deps in #79094, so regressions are caught going forward).

Why?

#78882 declared @types/react where packages' emitted declarations reference React types, but a full audit of the published artifacts showed more gaps, and one placement issue in #78882 itself:

• @types/react as a hard dependency while react is a peer is the wrong placement. When react is supplied by the consumer, the React type version must match the consumer's React too. A hard dependency drags in our own copy, which can collide with the consumer's @types/react (two structurally-incompatible JSX namespaces) and defeats the decoupling that made react a peer in the first place. The type surface should mirror the runtime surface: an optional peerDependency (optional so pure-JS consumers see no install warning). This is the established pattern in the React ecosystem.
• Some packages import react/jsx-runtime at runtime without declaring react at all.
• Some packages reference modules in their published files that resolve today only via root hoisting or a workspace link — the exact bug class of Fix missing dependencies for packages #74310 and components: Fix generated TS types referencing unavailable csstype #74655.
• @wordpress/data leaked rememo's types into six consumers' declarations. createSelector was a bare re-export, so consumers' inferred selector types were emitted as ... & import("rememo").EnhancedSelector in their .d.ts, and they do not declare rememo. With skipLibCheck: true those exports silently degrade to any for npm consumers.

How?

• @types/react moves from dependencies to an optional peerDependency in the 38 packages where react is a peer (or where only the types are referenced). @wordpress/element keeps it as a dependency since it depends on react directly.
• react (^18.0.0) is added as a peer to the four packages that import react/jsx-runtime at runtime but never declared it: connectors, content-types, lazy-editor, react-i18n.
• Genuinely missing dependencies are declared: @ariakit/react-core (components), redux (editor), @preact/signals-core (interactivity), rimraf (scripts); storybook moves from dev to prod dependencies in design-system-mcp (its emitted types reference it).
• @wordpress/theme declares its bundler plugins' host tools — postcss, esbuild, vite — as optional peers, following its existing stylelint plugin pattern.
• @wordpress/data now owns the createSelector types: create-selector.ts declares EnhancedSelector/GetDependants and annotates the export explicitly (same runtime function, zero behavior change), so consumers' emitted declarations reference import("@wordpress/data") instead of rememo. The two types are re-exported from the package index because TypeScript requires the type to be nameable through the package's public entry to emit a portable reference (TS2883 otherwise).

No runtime changes anywhere; npm run build type-checks clean and the regenerated packages/data/README.md API docs are included.

Testing Instructions

1. npm ci
2. npm run build — confirm the build and type checks pass.
3. grep -r 'import("rememo")' packages/*/build-types/ — confirm zero hits (on trunk, 6 packages emit such references).
4. Optionally audit any package's published surface: npx @mawesome/dependency-audit packages/<name>.

Testing Instructions for Keyboard

N/A — dependency declaration and type-only changes, no UI.

Screenshots or screencast

N/A.

Use of AI Tools

Used Claude Code (with the dependency-audit tool) to identify the affected packages, apply the dependency moves, and validate the results; the Codex CLI reviewed the createSelector type-ownership approach. The diff was reviewed before submission.