fix: declare the @types packages the published types import - #5821

ℹ️ No blocking issues. One ordering nit and a couple of test-quality notes inline.

Reviewed changes

• Optional @types/* peers — @types/node, @types/react, @types/react-dom are declared as optional peer dependencies so TypeScript resolves the packages the published .d.ts files import from where styled-components physically lives, not only under a hoisted tree.
• packaging-types.test.ts — new suite locking that every dependency/peer shipping no types has an @types sibling declared, that @types/node is present while sources name NodeJS., and that every @types peer is marked optional.
• Changeset — patch entry describing the consumer-visible fix.

I verified the peer additions do not require a lockfile change (pnpm install --frozen-lockfile reports "Lockfile is up to date", since the @types/* are already devDependencies and pnpm dedups them), confirmed each dependency/peer's type-shipping status, and checked there is no stylis type import and no other NodeJS. use outside ServerStyleSheet.tsx.

ℹ️ The new test guards the manifest, not the resolution behavior

The regression only surfaces under an isolated linker with skipLibCheck: false; the jest suite runs hoisted, so packaging-types.test.ts can assert the package.json contract but not that tsc actually resolves react, react-dom/server and NodeJS from the package location. That is an acceptable scope given the manual packed-tarball verification in the PR description — flagging it only so the guard is not mistaken for behavioral coverage of the consumer failure mode.

ℹ️ Nitpicks

• The test docblock says the assertions lock "anything the public types reach for is named in package.json". The first it only reaches packages already listed in dependencies/peerDependencies, so it would not catch a brand-new external import that is undeclared entirely. Narrowing that wording would keep the comment honest.
• shipsOwnTypes calls require.resolve(\${name}/package.json`)` for every dependency and peer. If an optional peer is ever absent from a given install layout, the test throws instead of reporting the offending package. A try/catch that fails with the package name would make the failure legible.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

ℹ️ No critical issues — one observation below.

Reviewed changes

• Raised the @types/react and @types/react-dom peer floors from * to >= 19.0.0, matching the react / react-dom runtime peers.
• Removed packages/styled-components/src/test/packaging-types.test.ts, the manifest-contract suite that guarded the @types/* declarations.
• Moved the three @types/* keys to the head of peerDependencies and peerDependenciesMeta, so the two objects agree and sort first (addresses the prior review's ordering nit).

I verified the floor change does not re-break resolution: installing the package into a scratch pnpm 10 consumer under an isolated virtual store, a @types/react@18 consumer with the >= 19 peer still has its copy linked into the package's virtual-store node_modules, so TypeScript resolves it. An absent optional peer emits no warning, so the JS-only consumer claim holds.

ℹ️ The manifest contract is no longer guarded

Deleting packaging-types.test.ts leaves nothing in the suite that fails if the @types/* peers are dropped, reordered, or stripped of peerDependenciesMeta.optional. treeshake.test.ts already asserts package.json shape (sideEffects, the browser field, subpath entries) and is the natural home. The caveat from the prior review still stands — jest runs hoisted, so a manifest test cannot prove isolated-linker resolution — but it would pin the declaration this fix depends on, which the repo's strict-TDD mandate otherwise expects.

# Restore a manifest guard for the `@types/*` peers

## Affected sites
- `packages/styled-components/src/test/packaging-types.test.ts` — deleted; was the only test asserting the `@types/*` peers and their optional flags.
- `packages/styled-components/src/test/treeshake.test.ts:642` — existing precedent for `package.json`-shape assertions.

## Required outcome
- A suite-level test that fails if any of `@types/react`, `@types/react-dom`, `@types/node` is removed from `peerDependencies`, or loses its `peerDependenciesMeta.optional: true`, or if any untyped dependency lacks a declared `@types` sibling.

## Open questions for the human
- Is the manifest guard wanted at all, or is the packed-tarball manual verification in the PR body considered sufficient for a metadata-only change?

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}