Add @types/react as an optional peer dependency

[unrevised6419]

Summary

react-error-boundary ships type declarations that depend on @types/react, but never declares that dependency. This PR adds it as an optional peer dependency — a manifest-only change, no code touched.

"peerDependencies": {
  "@types/react": "^18.0.0 || ^19.0.0",
  "react": "^18.0.0 || ^19.0.0"
},
"peerDependenciesMeta": {
  "@types/react": { "optional": true }
}

The problem

dist/react-error-boundary.d.ts (v6.1.2) imports 12 type-only symbols from react:

import { Component } from 'react';
import { ComponentClass } from 'react';
import { ComponentType } from 'react';
import { Context } from 'react';
import { ErrorInfo } from 'react';
import { ForwardRefExoticComponent } from 'react';
import { FunctionComponentElement } from 'react';
import { PropsWithChildren } from 'react';
import { PropsWithoutRef } from 'react';
import { ProviderProps } from 'react';
import { ReactNode } from 'react';
import { RefAttributes } from 'react';

@types/react appears only in devDependencies (^19.1.8). The react package itself ships no types, so a consumer's TypeScript has to locate @types/react on its own — via ambient node_modules layout that this package neither declares nor controls.

How it breaks today

Reproduced in a pnpm 11.21.0 monorepo with enableGlobalVirtualStore: true. Under that layout packages live in a global store outside the consuming project (~/Library/pnpm/store/v11/links/@/react-error-boundary/6.1.2/<hash>/node_modules/react-error-boundary), so TypeScript walking up from the published .d.ts never reaches the consumer's node_modules.

tsc --traceResolution, starting from the published declaration file:

======== Module name 'react' was successfully resolved to
'.../links/@/react/18.3.1/<hash>/node_modules/react/index.js'
with Package ID 'react/index.js@18.3.1'. ========

It lands on index.js — the untyped runtime entry — instead of @types/react. Component then has no props, and every consumer gets:

error TS2607: JSX element class does not support attributes because it does not have a 'props' property.
error TS2786: 'ErrorBoundary' cannot be used as a JSX component.
  Its type 'typeof ErrorBoundary' is not a valid JSX element type.
    Types of construct signatures are incompatible.
      Type 'new (props: any) => ErrorBoundary' is not assignable to type 'new (props: any, deprecatedLegacyContext?: any) => Component<any, any, any>'.
        Type 'ErrorBoundary' is missing the following properties from type 'Component<any, any, any>': context, setState, forceUpdate, props, and 2 more.

After the fix

Verified by simulating the manifest above through a pnpm packageExtensions override, then reinstalling. The package's store directory gains @types as a sibling and the trace becomes:

======== Module name 'react' was successfully resolved to
'.../links/@types/react/18.3.31/<hash>/node_modules/@types/react/index.d.ts'
with Package ID '@types/react/index.d.ts@18.3.31'. ========

Both TS2607 and TS2786 disappear.

Why optional: true

JavaScript-only consumers have no @types/react. Under strictPeerDependencies — or npm's default peer auto-install — a required peer would fail their install for a dependency they have no use for. Marking it optional is the standard pattern for a types-only peer.

Why the range mirrors the react peer

The range only validates — the peer itself resolves from the consumer, so their @types/react version wins either way. Confirmed in the verification above: the test workspace pins 18.3.31 while this repo's devDependencies list ^19.1.8, and resolution correctly lands on 18.3.31.

So the range's job is to state what this package's declarations actually support, and ^18.0.0 || ^19.0.0 keeps that identical to the existing react peer. Pinning ^19 alone would wrongly force React 19 types onto React 18 consumers; a bare "*" would go the other way and never flag a genuinely incompatible types major. Mirroring is also what comparable packages do — @testing-library/react declares exactly "^18.0.0 || ^19.0.0" optional, zustand declares ">=18.0.0" optional, both matching their own react peer.

Happy to widen it to "*" if you'd rather not have to touch it again when React 20 lands — though the react peer range would need the same release at that point anyway.

Why this is worth fixing now

Classic node_modules layouts work today by accident, not by design. pnpm's default hoistPattern: ['*'] puts @types/react in node_modules/.pnpm/node_modules/, which happens to sit on the upward walk from every virtual-store package; npm and yarn hoist it to the project root, same accident. A global virtual store removes the accident and the undeclared dependency becomes a hard error.

pnpm has stated the global virtual store is intended to become the default. At that point every TypeScript consumer of this package hits this, not only those who opted in early.

Verification in this repo

• pnpm run tsc — clean
• pnpm run test:ci — 21/21 passing
• prettier --check package.json — clean
• pnpm install --frozen-lockfile --recursive — no lockfile change

Note this is a published-manifest change, so it needs a release to reach consumers.

Happy to open an issue for discussion first if you'd prefer that per CONTRIBUTING.md — I read the manifest-only scope as outside "changes to this API", but that's your call.

🤖 Generated with Claude Code

[vercel]

@unrevised6419 is attempting to deploy a commit to the Brian Vaughn's projects Team on Vercel.

A member of the Team first needs to authorize it.

[unrevised6419]

LGTM

[bvaughn]

Thanks!

[bvaughn]

Published in version 6.1.3

[unrevised6419]

Thanks a lot!