Clarify RSC React compatibility policy#3732
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
WalkthroughThis PR clarifies the React Server Components generator version policy by documenting and validating that React 19.0.x (patch >= 19.0.4) pairs with an exact ChangesRSC version policy alignment
🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Greptile SummaryThis PR clarifies the React version compatibility policy for generated RSC apps:
Confidence Score: 4/5Safe to merge — all logic stays unchanged; this is a documentation and comment clarification with one new spec. The Ruby source change is purely comments, the three doc files are internally consistent with each other and with the constants in js_dependency_manager.rb, and the new spec correctly exercises the ~19.0.4 boundary. The only non-obvious element is the spec's implicit reliance on RubyGems and npm sharing equivalent ~ semantics for three-part versions, which works but is undocumented. react_on_rails/spec/react_on_rails/generators/js_dependency_manager_spec.rb — the Gem::Requirement proxy for npm semver is correct but benefits from an explanatory comment. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[RSC Generator invoked] --> B{use_rsc?}
B -->|yes| C["add_react_dependencies\nreact at ~19.0.4\nreact-dom at ~19.0.4"]
B -->|yes| D["add_rsc_dependencies\nreact-on-rails-rsc at 19.0.5-rc.6 exact"]
B -->|no| E[skip RSC packages]
C --> F{"React version\nin ~19.0.4 range?"}
F -->|"19.0.4 to 19.0.x"| G[Accepted]
F -->|"less than 19.0.4 or 19.1.0 plus"| H[Rejected]
D --> I["Exact pin - no range resolution\nuntil stable 19.0.5 ships"]
Reviews (1): Last reviewed commit: "Clarify RSC React compatibility policy" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| it "keeps the generated RSC React policy on the 19.0.x patch track" do | ||
| range = ReactOnRails::Generators::JsDependencyManager::RSC_REACT_VERSION_RANGE | ||
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) |
There was a problem hiding this comment.
~ range semantics to Gem::Requirement/Gem::Version, relying on the coincidental equivalence that RubyGems ~> X.Y.Z (3-part) and npm ~X.Y.Z both resolve to >= X.Y.Z, < X.(Y+1). That equivalence is real and the test cases are correct, but it's non-obvious to a future reader — a brief inline comment would clarify why this cross-ecosystem proxy is valid here and prevent someone from "fixing" it to a pure string comparison that doesn't actually exercise the range.
| it "keeps the generated RSC React policy on the 19.0.x patch track" do | |
| range = ReactOnRails::Generators::JsDependencyManager::RSC_REACT_VERSION_RANGE | |
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) | |
| it "keeps the generated RSC React policy on the 19.0.x patch track" do | |
| range = ReactOnRails::Generators::JsDependencyManager::RSC_REACT_VERSION_RANGE | |
| # npm `~X.Y.Z` and RubyGems `~> X.Y.Z` have equivalent semantics for a | |
| # three-part version: both mean `>= X.Y.Z, < X.(Y+1)`. We exploit that | |
| # equivalence here so we can validate the npm range with Gem::Requirement | |
| # without pulling in a Node runtime. | |
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 91366ab4a3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # pnpm add react@19.0.4 react-dom@19.0.4 react-on-rails-rsc@19.0.5-rc.6 | ||
| # bun add react@19.0.4 react-dom@19.0.4 react-on-rails-rsc@19.0.5-rc.6 | ||
| yarn add react@~19.0.4 react-dom@~19.0.4 react-on-rails-rsc@19.0.5-rc.6 | ||
| # npm install react@~19.0.4 react-dom@~19.0.4 react-on-rails-rsc@19.0.5-rc.6 |
There was a problem hiding this comment.
When users follow the npm variant here, react-on-rails-rsc@19.0.5-rc.6 will not be kept as the exact pin this section now requires: I checked the local npm semantics (npm install --help exposes -E|--save-exact, and npm config ls -l shows save-exact = false with save-prefix = "^"). That means an app can record a range for the RSC RC and later drift even though the surrounding note says to keep the exact generator pin; use the package-manager exact flag, as the generator’s own manual recovery command does.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Code ReviewOverall: Solid, low-risk PR. Docs are clearer and more actionable, and the spec addition meaningfully validates the tilde-range semantics rather than just string-matching the constant. Scoping is tight — only Spec:
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| it "pins react-on-rails-rsc to the React 19 compatibility track" do | ||
| it "keeps the generated RSC React policy on the 19.0.x patch track" do | ||
| range = ReactOnRails::Generators::JsDependencyManager::RSC_REACT_VERSION_RANGE | ||
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) |
There was a problem hiding this comment.
The ~ → ~> substitution is clever but non-obvious: it converts npm's tilde range (~19.0.4 = >=19.0.4 <19.1.0) to Ruby's pessimistic constraint operator (~> 19.0.4 = >= 19.0.4, < 19.1). For three-component versions with non-prerelease inputs the two semantics are equivalent, which is why the five test cases below are correct.
A one-liner comment here would help future readers avoid wondering whether this is accidentally using gem-version semantics to validate npm behaviour:
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) | |
| # npm `~x.y.z` and Ruby `~> x.y.z` are equivalent for three-part non-prerelease versions: | |
| # both allow only patch increments within the same minor (>=x.y.z <x.(y+1).0). | |
| requirement = Gem::Requirement.new(range.sub(/\A~/, "~> ")) |
Core Benchmark Summary
▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline |
Pro (shard 1/2) Benchmark Summary
▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline |
Pro (shard 2/2) Benchmark Summary
▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline |
1 participant
Summary
Fixes #3620 by documenting and testing the current generated-RSC compatibility policy.
19.0.xvia~19.0.4, not React 19.1/19.2 just because those versions are current on npm.react-on-rails-rscas an exact19.0.5-rc.6generator pin until a stable19.0.5release ships.Live package evidence
npm view react-on-rails-rsc dist-tags versions version peerDependencies --jsonlatest:19.0.4next:19.0.5-rc.619.0.5is publishedreact: ^19.0.3,react-dom: ^19.0.3,webpack: ^5.59.0npm view react react-dom react-server-dom-webpack dist-tags version peerDependencies --jsonreact@latest:19.2.7react-dom@latest:19.2.7, peerreact: ^19.2.7react-server-dom-webpack@latest:19.2.7, peersreact: ^19.2.7,react-dom: ^19.2.7,webpack: ^5.59.0Validation
bundle exec rspec react_on_rails/spec/react_on_rails/generators/js_dependency_manager_spec.rbpnpm prettier --check docs/pro/react-server-components/upgrading-existing-pro-app.md docs/pro/react-server-components/create-without-ssr.md docs/pro/react-server-components/rspack-compatibility.mdscript/ci-changes-detector origin/main30ec8e12b95b3ca56cee8f46ba62e6dde2b9433dgit diff --check origin/main..HEADjs_dependency_manager.rb,js_dependency_manager_spec.rb, and the targeted RSC docs.install_generator_spec.rb, active RSC generator PR files, workflow files,rsc_setup.rb, orrsc_use_client_css.spec.ts.Note
Low Risk
Documentation, comment, and spec-only changes; generator dependency constants are unchanged, so install behavior is unaffected.
Overview
Documents and tests the generated RSC compatibility policy (fixes #3620): apps should stay on React
19.0.xviareact@~19.0.4/react-dom@~19.0.4(patch ≥ 19.0.4), not 19.1/19.2, and keepreact-on-rails-rsc@19.0.5-rc.6as an exact pin until stable 19.0.5 ships.Docs (
create-without-ssr,upgrading-existing-pro-app,rspack-compatibility) switch manual install examples from exact19.0.4to~19.0.4, tighten prerequisite/troubleshooting tables, add a React and Package Version Policy section for Rspack, and explain that Pro peer metadata (#3609) can differ from generator install pins.Generator (
js_dependency_manager.rb): richer comments onRSC_REACT_VERSION_RANGEvsRSC_PACKAGE_VERSION_PIN—no constant value changes in this diff.Tests:
js_dependency_manager_specasserts~19.0.4accepts 19.0.4/19.0.7 and rejects 19.0.3/19.1.0/19.2.7.Reviewed by Cursor Bugbot for commit 91366ab. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit
Release Notes