chore(deps): update dependency @types/react to v18.3.28 - autoclosed#828
chore(deps): update dependency @types/react to v18.3.28 - autoclosed#828ham-renovate wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughTypeScript React type definitions are updated across multiple package.json files. The root and blabsy client packages update Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@package.json`:
- Around line 55-60: The monorepo-wide "overrides" block is forcing
`@types/react`@18.3.28 which conflicts with the calendar package that uses React
19; update the overrides so types stay consistent: either (A) lock both
`@types/react` and `@types/react-dom` to ^18 (e.g., set both to a compatible ^18
range) if the monorepo standardises on React 18, or (B) remove or narrow the
override scope so it does not apply to the calendar workspace (allowing the
calendar to resolve `@types/react`@^19 and `@types/react-dom`@^19); edit the
"overrides" section to adjust or remove the `@types/react` and `@types/react-dom`
entries accordingly and verify calendar/client/package.json dependencies align
with the chosen strategy.
In `@platforms/calendar/client/package.json`:
- Around line 67-68: The package declares mismatched type packages for React (
`@types/react`: ^18.x vs `@types/react-dom`: ^19 ) which will produce type errors;
fix by either aligning both to the same major version: change this workspace's
dependency `@types/react-dom` to an 18.x release to match the root-enforced
`@types/react` 18.x, or remove/exclude this workspace from the monorepo root
override so the calendar package can use `@types/react`@^19 and
`@types/react-dom`@^19 to match react/react-dom ^19.0.0; update the package.json
dependencies in the calendar client (and the root overrides entry) accordingly
and run a fresh install to verify types.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (3)
package.jsonplatforms/blabsy/client/package.jsonplatforms/calendar/client/package.json
| "overrides": { | ||
| "react": "18.3.1", | ||
| "react-dom": "18.3.1", | ||
| "@types/react": "18.3.27", | ||
| "@types/react": "18.3.28", | ||
| "@types/react-dom": "18.3.7" | ||
| } |
There was a problem hiding this comment.
Monorepo-wide @types/react override forces React 18 types onto the calendar package (React 19 runtime).
The overrides block pins @types/react to 18.3.28 for every workspace in the monorepo. Setting pnpm overrides like this will effectively fix the installed version by always resolving @types/react to the specified version. Because the calendar package runs React 19 (react: ^19.0.0), it will be missing type definitions for React 19-specific APIs, and the resulting split (@types/react@18 + @types/react-dom@19) risks JSX-contract incompatibilities as flagged above.
If the monorepo intentionally standardises on React 18 types, both @types/react and @types/react-dom should be locked to ^18 in the override (and @types/react-dom: "^19" in calendar/client/package.json updated accordingly). If the calendar package should eventually consume React 19 types, the override scope should be narrowed to only the workspaces that need v18.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` around lines 55 - 60, The monorepo-wide "overrides" block is
forcing `@types/react`@18.3.28 which conflicts with the calendar package that uses
React 19; update the overrides so types stay consistent: either (A) lock both
`@types/react` and `@types/react-dom` to ^18 (e.g., set both to a compatible ^18
range) if the monorepo standardises on React 18, or (B) remove or narrow the
override scope so it does not apply to the calendar workspace (allowing the
calendar to resolve `@types/react`@^19 and `@types/react-dom`@^19); edit the
"overrides" section to adjust or remove the `@types/react` and `@types/react-dom`
entries accordingly and verify calendar/client/package.json dependencies align
with the chosen strategy.
| "@types/react": "^18.3.27", | ||
| "@types/react-dom": "^19", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate and read the calendar package.json file
find . -path "*/platforms/calendar/client/package.json" -type fRepository: MetaState-Prototype-Project/prototype
Length of output: 121
🏁 Script executed:
# Read the calendar client package.json around lines 50-70 to see React versions and types
cat -n platforms/calendar/client/package.json | sed -n '50,75p'Repository: MetaState-Prototype-Project/prototype
Length of output: 926
🏁 Script executed:
# Find and read the root package.json to check for overrides
find . -maxdepth 1 -name "package.json" -type f -exec cat -n {} \;Repository: MetaState-Prototype-Project/prototype
Length of output: 2582
🏁 Script executed:
# Check `@types/react-dom`@19 peer dependencies by searching for any lock files or package metadata
fd -t f "(pnpm-lock.yaml|package-lock.json|yarn.lock)" --max-results 1Repository: MetaState-Prototype-Project/prototype
Length of output: 95
🏁 Script executed:
# Check pnpm-lock.yaml for `@types/react-dom`@19 and its dependencies
grep -A 10 "@types/react-dom@19" pnpm-lock.yaml | head -20Repository: MetaState-Prototype-Project/prototype
Length of output: 63
🏁 Script executed:
# Search for the `@types/react-dom` package entry to see peer deps
grep -B 2 -A 15 "name: '@types/react-dom'" pnpm-lock.yaml | grep -A 15 "version: '19'"Repository: MetaState-Prototype-Project/prototype
Length of output: 63
🌐 Web query:
@types/react-dom 19 peer dependency @types/react compatibility
💡 Result:
@types/react-dom@19.x is intended to be used with @types/react@19.x (i.e., keep the React type packages on the same major, and ideally the same minor/patch to avoid duplicate/competing React type copies in a monorepo). React’s own React 19 upgrade guide explicitly recommends updating both together (e.g. @types/react@^19.0.0 + @types/react-dom@^19.0.0). [1]
Although package metadata sources show @types/react-dom declares a dependency/peer on @types/react (often effectively “any”), in practice mismatching majors is a common cause of TS incompatibilities (e.g., ReactNode conflicts), so the safe compatibility rule is:
@types/react-dom@19.*⇔@types/react@19.*(recommended) [1][2]
As of Nov 12, 2025, the latest published @types/react-dom in the 19 line is 19.2.3. [2]
Sources:
[1] React 19 Upgrade Guide (TypeScript install commands) (react.dev)
[2] Snyk version list showing latest @types/react-dom 19.2.3 and publish date (security.snyk.io)
Citations:
- 1: https://react.dev/blog/2024/04/25/react-19-upgrade-guide?utm_source=openai
- 2: https://security.snyk.io/package/npm/%40types%2Freact-dom/versions?utm_source=openai
@types/react (v18) and @types/react-dom (v19) are at different major versions — this will cause type incompatibilities.
This package runs React 19 (react: ^19.0.0, react-dom: ^19.0.0) but declares @types/react: ^18.3.27 while keeping @types/react-dom: ^19. The root pnpm override forces @types/react to 18.3.28 for all workspaces, but this package explicitly declares @types/react-dom: ^19, creating a major version split. According to React's official upgrade guide and type package documentation, @types/react-dom@19.x must be paired with @types/react@19.x — a mismatch between these two type packages is a known source of type errors (e.g., ReactNode incompatibilities).
To fix this, either:
- Downgrade
@types/react-domto v18 to align with the enforced@types/react@18from the root override, or - Remove this workspace from the root override to allow it to use React 19 types consistently (requires separating this package's type versions from the monorepo-wide policy).
Option A — align @types/react-dom to v18
- "@types/react-dom": "^19",
+ "@types/react-dom": "^18",Option B — exclude this workspace from the root `@types/`* override
Modify the root package.json override to target other workspaces only, allowing the calendar package to use @types/react@^19 and @types/react-dom@^19 consistently with its React 19 runtime.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "@types/react": "^18.3.27", | |
| "@types/react-dom": "^19", | |
| "@types/react": "^18.3.27", | |
| "@types/react-dom": "^18", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@platforms/calendar/client/package.json` around lines 67 - 68, The package
declares mismatched type packages for React ( `@types/react`: ^18.x vs
`@types/react-dom`: ^19 ) which will produce type errors; fix by either aligning
both to the same major version: change this workspace's dependency
`@types/react-dom` to an 18.x release to match the root-enforced `@types/react`
18.x, or remove/exclude this workspace from the monorepo root override so the
calendar package can use `@types/react`@^19 and `@types/react-dom`@^19 to match
react/react-dom ^19.0.0; update the package.json dependencies in the calendar
client (and the root overrides entry) accordingly and run a fresh install to
verify types.
ham-renovate
changed the title
1 participant
This PR contains the following updates:
18.3.27→18.3.28^19→^18.3.27Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Renovate Bot.