Desired outcome
The React type packages match the React version the site actually runs.
Why it matters
package.json pins the runtime at React 18:
"react": "18.3.1",
"react-dom": "18.3.1",
but the types at React 19:
"@types/react": "19.1.0",
"@types/react-dom": "19.1.2",
The 19 typings drop React.FC implicit children, change ReactNode and the ref types, and describe APIs that do not exist in the installed runtime. In practice that means the type checker can accept code that breaks at runtime, and it can reject correct React 18 code. It also makes contributor setups inconsistent, since anyone who runs a fresh install sees type errors that do not reproduce for others.
Steps
- Decide the direction. The simple one is to pin the types to React 18:
"@types/react": "^18.3.x" and "@types/react-dom": "^18.3.x".
- Alternatively upgrade the runtime to React 19, which Next 15.5 supports, and leave the types as they are. That is the larger change and needs a pass over the components.
- Run
npx tsc --noEmit and npm run build after either change and fix any fallout in the same PR.
Claiming this
Comment below to claim it. A reply usually comes within a day.
Desired outcome
The React type packages match the React version the site actually runs.
Why it matters
package.jsonpins the runtime at React 18:but the types at React 19:
The 19 typings drop
React.FCimplicitchildren, changeReactNodeand the ref types, and describe APIs that do not exist in the installed runtime. In practice that means the type checker can accept code that breaks at runtime, and it can reject correct React 18 code. It also makes contributor setups inconsistent, since anyone who runs a fresh install sees type errors that do not reproduce for others.Steps
"@types/react": "^18.3.x"and"@types/react-dom": "^18.3.x".npx tsc --noEmitandnpm run buildafter either change and fix any fallout in the same PR.Claiming this
Comment below to claim it. A reply usually comes within a day.