Pro RSC migration 1/3: Swap gem and npm to react_on_rails_pro#726
Conversation
First of three stacked sub-PRs enabling React Server Components here, since enable_rsc_support is a Pro-only configuration. Pure dependency swap — ExecJS server rendering and existing behavior are unchanged. - Gemfile: react_on_rails 16.6.0.rc.0 → react_on_rails_pro 16.6.0 - package.json: react-on-rails 16.6.0-rc.0 → react-on-rails-pro 16.6.0 - shakapacker: rc.0 → 10.0.0 stable (lockstep with the Pro gem pair) - commonWebpackConfig.js: alias react-on-rails → react-on-rails-pro so third-party packages still importing 'react-on-rails' (such as rescript-react-on-rails) resolve to Pro. Prevents the runtime error "Cannot mix react-on-rails (core) with react-on-rails-pro". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
🚀 Quick Review App CommandsWelcome! Here are the commands you can use in this PR:
|
Code Review: Pro RSC Migration 1/3 — Gem/NPM SwapOverviewClean, well-scoped dependency swap: RC versions out, stable Pro versions in. The stacked-PR strategy is well-explained and the scope is appropriately limited to just the package swap. No functional behavior changes are claimed, which matches the diff. What's Good
IssuesWebpack alias coverage gap The alias only covers two import paths: 'react-on-rails$': 'react-on-rails-pro',
'react-on-rails/node_package': 'react-on-rails-pro/node_package',If A single alias without the alias: {
'react-on-rails': 'react-on-rails-pro', // catches exact import AND any sub-paths
},The only risk would be if First-party code still imports Application bundle code contains Production license handling not addressed The dev log shows Minor Notes
Overall, solid groundwork for the RSC migration. Main things to address before merge: simplify the webpack alias (drop the |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
The previous commit aliased all 'react-on-rails' imports to 'react-on-rails-pro' at bundle time. That worked but left two things sloppy: 1. First-party code still read as if it depended on the core package, hiding the real Pro dependency behind a webpack alias. Anyone reading the source couldn't tell we were on Pro. 2. The alias had a '/node_package' sub-path entry that was legacy — neither package actually ships a node_package/ folder, and nothing imports that path anywhere in the tree. Rewriting first-party imports to 'react-on-rails-pro' directly matches the react_on_rails :pro generator's update_imports_to_pro_package step and makes the dependency legible. The webpack alias is now narrowed to its real job: shimming rescript-react-on-rails (the one third-party package still importing 'react-on-rails'), and only for exact-specifier imports — Pro's package exports don't mirror core's sub-path surface, so a prefix alias could break resolution for OSS-only sub-paths. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Code Review: Pro RSC Migration 1/3 — Dependency SwapOverall: Clean, well-scoped PR. The changes are consistent, the lockfiles are properly updated, and the webpack alias approach is the right solution for the third-party compat problem. A few things worth flagging before this lands. ✅ What's done well
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
License: deferring to Sub-PR 2 where NodeRenderer activates and the license becomes load-bearing. This PR stays on ExecJS, so the Pro engine just logs the dev-environment notice. Sub-PR 2 adds |
|
✅ Review app for PR #726 was successfully deleted |
… Components demo
Migrates this tutorial to React on Rails Pro with the Pro Node Renderer
for SSR, and adds a React Server Components demo at /server-components.
RSC is a Pro-only feature (`enable_rsc_support` doesn't exist in the OSS
gem), so demonstrating RSC inherently moves the whole app to Pro —
that's the entry ticket, not scope drift.
What changes:
- Dependencies: gem and npm move from react_on_rails to
react_on_rails_pro 16.6.0; React pinned to ~19.0.4 (RSC's minimum);
adds react-on-rails-pro-node-renderer and react-on-rails-rsc.
- SSR runtime: Server-side rendering moves from ExecJS to the Pro Node
Renderer (renderer/node-renderer.js, port 3800). The renderer wires
additionalContext: { URL, AbortController } for react-router-dom,
stubTimers: false so React's RSC server renderer can use setTimeout
for Flight-protocol yielding, and replayServerAsyncOperationLogs:
true to surface async-server-component console output.
- RSC demo: A new page at /server-components exercises React Server
Components end-to-end: server-only library imports (Node os +
lodash) that never reach the browser, async server components
streamed via <Suspense>, the donut pattern (a 'use client' component
nested in a server tree), and client-driven server-component
re-fetching with react-error-boundary + useRSC().refetchComponent.
- Bundler: shakapacker temporarily switched from rspack to webpack
while waiting for shakacode/react_on_rails_rsc#29 to ship rspack
support for the RSC plugin. Tracked by TODO in
config/shakapacker.yml.
Verification:
- Each sub-PR (#726, #728, #729) reviewed independently before
squashing into base.
- Manually QA'd on the deployed review app.
- Request and system specs cover the RSC payload endpoint and the
demo page interactions (spec/requests/server_components_spec.rb,
spec/system/server_components_demo_spec.rb).
- Lint, RSpec, and JS test workflows ran for the first time on the
base PR — sub-PRs target the base branch and skip those workflows
by trigger filter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Part 1 of a stacked-PR series migrating this tutorial to React on Rails Pro so React Server Components can be demoed here (
enable_rsc_supportis Pro-only). Pure dependency swap — no functional change. ExecJS server rendering is still used; no Pro runtime features enabled yet.react_on_rails 16.6.0.rc.0→react_on_rails_pro 16.6.0react-on-rails 16.6.0-rc.0→react-on-rails-pro 16.6.010.0.0.rc.0→10.0.0stable (lockstep with the Pro gem)'react-on-rails'→'react-on-rails-pro'across 10 files (matchesreact_on_rails :progenerator'supdate_imports_to_pro_packagestep)config/webpack/commonWebpackConfig.js: narrow aliasreact-on-rails$→react-on-rails-proto shim the one third-party package still importing the core specifier (rescript-react-on-rails). Prevents the runtime "Cannot mix react-on-rails (core) with react-on-rails-pro" error.Supersedes PR #723
PR #723 bundled the full migration (gem swap + NodeRenderer + RSC demo + a custom Rspack RSC plugin) in a single branch. This stacked series splits that work into focused sub-PRs and realigns several choices with the canonical Pro references (
react_on_rails_pro/spec/dummy, marketplace demo). Branchihabadham/feature/pro-rsc/baseis the integration branch; sub-PRs target it, and it'll merge tomasteras one atomic unit once all three land.Stack context
Targets
ihabadham/feature/pro-rsc/base, notmaster. The base PR againstmasterwill open as Draft (with[DO NOT MERGE]title prefix) once this sub-PR merges and gives it a non-empty diff. Planned follow-ups:target: 'node',node: false, upstreamRSCWebpackPluginon the server bundle,create_pro_initializerwith NodeRenderer fields,renderer/node-renderer.jslauncher,Procfile.deventry, webpack transforms from the:progenerator'supdate_webpack_config_for_pro). This is where the production license story becomes load-bearing and gets handled (.env.example, CI secret).RSCWebpackPlugin,rscWebpackConfig.jsderived fromserverWebpackConfig(true), initializer RSC fields, server components page + routes,'use client'directives). No custom plugin, no separatersc-bundle.jssource, no manualrsc-client-components.jsside-import — all of that is replaced by the upstream plugin'sclientReferencesoption.shakapacker.ymlback to rspack onceshakacode/react_on_rails_rsc#29shipsRSCRspackPluginin a release. The manifest contract is shared between the two plugins, so it'll be a small diff.Test plan
bundle installresolvesreact_on_rails_pro 16.6.0;react_on_rails 16.6.0pulled in as transitiveyarn installresolves; one expectedrescript-react-on-railspeer-dep warning (handled by the narrowed webpack alias)bundle exec rake shakapacker:compile— clean build, 3 benign size warnings (pre-existing)bin/rails sboots clean; dev log shows[React on Rails Pro] No license found. No license required for development/test environments.GET /returns HTTP 200🤖 Generated with Claude Code