Bump react dep version to v19 #20
Conversation
WalkthroughEh, what's up, doc? The peer dependency for "react" in the ol' package.json got updated to add support for version 19.0.0, along with the previous versions 16, 17, and 18. Nothin' else changed in the file, so that's all, folks! Changes
Sequence Diagram(s)Nothin' to see here, doc—no new features or control flow changes in this batch! 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| "peerDependencies": { | ||
| "react": "^16.0.0 || ^17.0.0 || ^18.0.0", | ||
| "react": "^16.0.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", | ||
| "react-native": ">=0.57" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Eh, mismatch alert, doc!
You juiced up the peer range to include React 19, but the devDependencies are still munchin’ on the old v16 carrots ("react": "^16.0.0" and "@types/react": "^16.0.0"). That can bite you during local builds, tests, and type-checking because Yarn/NPM will hoist v16 while downstream apps expect v19 compatibility.
Consider bumping the dev deps (or dropping them entirely and relying on workspaces/PNPM resolutions) so your CI environment compiles against the highest supported version.
@@
- "@types/react": "^16.0.0",
- "react": "^16.0.0",
+ "@types/react": "^18.2.37", // latest available typings; adjust when 19 typings land
+ "react": "^19.0.0",Give it a quick spin to be sure no type or lint carrots pop up.
Eh, doc, let’s take a peek under the hood and see what versions are munchin’ on carrots in devDependencies:
🏁 Script executed:
#!/bin/bash
# Show the devDependencies block in package.json
rg -A10 '"devDependencies"' package.jsonLength of output: 357
DevDependencies Update Required
What’s up, doc? Our peerDependencies now support React 19, but devDependencies are still stuck on React 16—this can lead to hoisting surprises and type-checking hiccups in CI. Let’s bump them so we’re compiling against the highest supported version.
• File: package.json (devDependencies block)
Suggested diff:
"devDependencies": {
- "@types/react": "^16.0.0",
- "react": "^16.0.0",
+ "@types/react": "^18.2.37", // latest available typings; adjust when React 19 types land
+ "react": "^19.0.0",
"@types/react-native": "^0.57.0",
"prettier": "^2.1.1",
"react-native": "^0.57.0",
"typescript": "^5.2.2"
},Give it a quick spin to make sure no type or lint carrots pop up.
📝 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.
| "peerDependencies": { | |
| "react": "^16.0.0 || ^17.0.0 || ^18.0.0", | |
| "react": "^16.0.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", | |
| "react-native": ">=0.57" | |
| "devDependencies": { | |
| "@types/react": "^18.2.37", // latest available typings; adjust when React 19 types land | |
| "react": "^19.0.0", | |
| "@types/react-native": "^0.57.0", | |
| "prettier": "^2.1.1", | |
| "react-native": "^0.57.0", | |
| "typescript": "^5.2.2" | |
| }, |
🤖 Prompt for AI Agents
In package.json around lines 66 to 68, the devDependencies for React are
outdated compared to the peerDependencies which support React 19. Update the
React and React Native versions in the devDependencies block to match the
highest versions allowed in peerDependencies, specifically bump React to version
19 and React Native to at least 0.57 or higher as appropriate. After updating,
run the type checks and linting to ensure no errors or warnings appear.
There was a problem hiding this comment.
What are the implications of leaving this as is? We would want maximum compatibility but also recognize that certain libs are kinda old.
There was a problem hiding this comment.
@angelxmoreno Eh, what's up doc? Great question about keepin' those carrots fresh vs. old! Let me break down the implications of leavin' things as-is:
Implications of Keeping devDependencies at React 16:
🥕 The Good:
- Backward compatibility confidence - You're literally developing against the oldest supported version, so you know it works
- Simpler maintenance - No need to chase the latest React changes during development
- Smaller bundle - React 16 is lighter than newer versions for your dev environment
🐰 The Not-So-Good:
- Type blindness - You're missing newer React APIs, hooks improvements, and type definitions from v17-19
- CI gap - Your tests run against v16, but users might hit issues with v17-19 that you never see
- Hoisting hijinks - Package managers might hoist v16 during development, causing confusing behavior
- Developer experience - Contributors using newer React versions might get type mismatches
The Bugs Bunny Recommendation:
Since this is a library (not an app), I'd suggest a hybrid approach:
"devDependencies": {
"@types/react": "^18.2.37", // Latest stable types
"react": "^18.0.0", // Middle ground - not bleeding edge
// ... other deps
}Why React 18 in devDependencies?
- It's stable and well-tested
- Gives you better type coverage than v16
- React 19 is still pretty fresh - let it bake a bit more
- You still support v16-19 in peerDependencies
Pro tip: Consider adding a CI matrix that tests against multiple React versions if you really want belt-and-suspenders compatibility:
strategy:
matrix:
react-version: ['16', '17', '18', '19']What's your take, doc? Want to play it safe with the middle ground, or stick with the current approach for maximum backward compatibility?
(°◡°)♡
2 participants
Summary by CodeRabbit