No actionable comments were generated in the recent review. 🎉

Walkthrough

New test assertions were added to install_generator_spec.rb validating the --rsc-pro generator mode. The tests confirm generation of RSC webpack configurations, HelloServer scaffold components, Procfile.dev watcher entries, node-renderer bootstrapping, and route mappings.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Poem

🐰 A rabbit hops through test files with glee,
Asserting that bundles and configs agree—
RSC Pro mode now proven and true,
With webpack and routes and HelloServer too!
Tests pass like clover, abundant and green,
The finest generator assertions I've seen! 🌱

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 help to get the list of available commands and usage tips.}

Greptile Summary

Closes the --rsc-pro generator test gap by adding 7 new it blocks that mirror the existing --rsc assertions: node-renderer.js creation, Procfile.dev RSC bundle watcher entries, HelloServer scaffold (no HelloWorld), routes for hello_server and rsc_payload, rscWebpackConfig.js wiring, and serverWebpackConfig.js RSCWebpackPlugin/rscBundle checks. Also converts scriptSanitizedVal from an anonymous arrow-function export to a named function export — functionally identical.

Confidence Score: 5/5

Safe to merge — test-only additions with a no-op source refactor.

All changes are either new RSpec assertions (no production impact) or a semantically equivalent function-declaration refactor. The previous P1 gap around rscWebpackConfig.js assertions was resolved in commit 199d0cb before this review. No remaining findings rise above P2.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["run_generator_test_with_args(--rsc-pro)"] --> B["before(:all) – single generator run"]
    B --> C["include_examples rsc_common_files"]
    B --> D["include_examples rsc_hello_server_files"]
    B --> E["it: pins Pro dependencies"]
    B --> F["it: creates node-renderer.js NEW"]
    B --> G["it: adds RSC bundle watcher to Procfile.dev NEW"]
    B --> H["it: creates HelloServer instead of HelloWorld NEW"]
    B --> I["it: adds HelloServer route and RSC payload route NEW"]
    B --> J["it: creates rscWebpackConfig.js NEW"]
    B --> K["it: serverWebpackConfig includes RSCWebpackPlugin NEW"]
    B --> L["it: serverWebpackConfig has rscBundle parameter NEW"]
    B --> M["it: sets DEFAULT_ROUTE to hello_server in bin/dev"]
    C --> C1["Procfile.dev exists\nPro initializer content\nLayout content"]
    D --> D1["HelloServer controller layout\nHelloServer view stream_react_component"]
    J --> J1["serverWebpackModule require\nserverWebpackConfig(true)\nrsc-bundle / react-server"]
    K --> K1["RSCWebpackPlugin import\nreact-on-rails-rsc/WebpackPlugin"]
    L --> L1["configureServer=(rscBundle=false)\nif (!rscBundle) guard"]

_{Reviews (2): Last reviewed commit: "Add missing serverWebpackConfig.js asser..." | Re-trigger Greptile}

Review: Add comprehensive --rsc-pro generator tests

Good addition — this PR closes a real coverage gap. The 5 new assertions faithfully parallel the --rsc context and the test run confirms 12 passing examples. A couple of observations:

Weak assertions on rscWebpackConfig.js

The new creates rscWebpackConfig.js test only checks for rsc-bundle and react-server, whereas the equivalent --rsc test (line 1577) verifies 5 content strings including the full require path and function call:

expect(content).to include("const serverWebpackModule = require('./serverWebpackConfig')")
expect(content).to include("const serverWebpackConfig = serverWebpackModule.default || serverWebpackModule")
expect(content).to include("serverWebpackConfig(true)")
expect(content).to include("rsc-bundle")
expect(content).to include("react-server")

If --rsc-pro intentionally generates a different rscWebpackConfig.js (e.g. the Pro-flavoured version from rsc_generator_spec.rb which checks for rscConfig), the test should document that difference with more specific assertions — otherwise it is under-specified and unlikely to catch regressions. If the content is the same as --rsc, the full assertion set should be copied.

Duplication potential (minor, not blocking)

The tests for node-renderer.js, RSC bundle watcher, HelloServer files, and routes are byte-for-byte identical to the --rsc context. If these checks apply to every RSC mode (which seems likely), they might be better expressed as shared examples (similar to rsc_hello_server_files). This would avoid the same assertions drifting out of sync across contexts over time. Not a blocker, but worth considering if more RSC modes are added.

Review feedback addressed

Addressed:

• Added missing rscWebpackConfig.js assertions to the --rsc-pro test (199d0cb). Both modes use the same template, so the 5-assertion set now matches the --rsc counterpart.

Skipped (rationale):

• CodeRabbit summary — Bot status post, no action needed.
• Greptile summary — Bot status post; the P2 it flagged was addressed above.
• Shared examples suggestion (@claude[bot]) — Valid observation about test duplication across RSC modes, but this is a style preference and not blocking. The current structure keeps each context self-contained and easy to read. Worth revisiting if more RSC modes are added.

All review threads resolved. Tests pass (19 examples, 0 failures).

Review: Add comprehensive --rsc-pro generator tests

The direction is right — the gap between --rsc and --rsc-pro test coverage was real and worth closing. A few observations:

Missing: serverWebpackConfig.js assertions

The --rsc context has two tests for config/webpack/serverWebpackConfig.js that aren't in this PR:

• "serverWebpackConfig includes RSCWebpackPlugin import" — verifies RSCWebpackPlugin and react-on-rails-rsc/WebpackPlugin
• "serverWebpackConfig has rscBundle parameter" — verifies the configureServer = (rscBundle = false) signature and the if (!rscBundle) guard

Since --rsc-pro generates the same serverWebpackConfig.js shape, leaving these out means the coverage gap isn't fully closed despite the PR description's goal of matching --rsc thoroughness. See the inline comment for the exact test bodies to add.

Structural concern: copy-paste will drift again

Five of the six new tests are verbatim copies of their --rsc equivalents. This is how the gap opened in the first place (#2822 added behavior but not all the mirrored assertions). Extracting those five into a new shared example group (e.g. "rsc_and_rsc_pro_common_files") would make both contexts stay in sync automatically without another gap-closing PR.

Minor naming nit

In --rsc, the parallel test is "creates HelloServer instead of HelloWorld (controller, route, and components)" — the parenthetical is useful documentation. The new --rsc-pro variant drops it, which is slightly less self-describing.

Review

This is a solid addition — the --rsc-pro coverage gap from #2793 is real and the new tests are well-structured. A few things worth addressing:

Blocking / Correctness

Missing serverWebpackConfig.js coverage (see inline comment on rscWebpackConfig.js): The --rsc context has two tests verifying serverWebpackConfig.js structure (RSCWebpackPlugin import, rscBundle parameter) that are not present in --rsc-pro. If --rsc-pro produces the same file, those tests should be added here; if it produces a different file, --rsc-pro-specific assertions are needed. Without this, the stated goal of making --rsc-pro coverage "comparable to --rsc" is not fully achieved.

Non-blocking

• Unrelated file: packages/react-on-rails/src/scriptSanitizedVal.ts — arrow function → named function conversion — has no connection to the generator tests. Worth splitting out or at minimum calling out explicitly in the PR description.
• Test duplication: The node-renderer.js, Procfile.dev, and rscWebpackConfig.js tests are identical to their --rsc counterparts. A shared example would prevent silent divergence if the generator changes in the future.
• Test description inconsistency: Line 1750's description and the missing clarifying comment — minor, but easy to align with the --rsc version for consistency.

Overall the approach is correct and the tests themselves are well-written. Address the serverWebpackConfig.js gap and this is good to go.

size-limit report 📦

Review feedback addressed (round 2)

Addressed:

• Added missing serverWebpackConfig.js assertions to the --rsc-pro test (4d143df). Both RSCWebpackPlugin import check and rscBundle parameter check now mirror the --rsc counterpart. Tests pass: 14 examples, 0 failures.

Skipped (rationale):

• Shared examples suggestion (@claude[bot]) — Valid observation about test duplication, but intentionally keeping contexts self-contained for readability. Worth revisiting if more RSC modes are added.
• Naming nit (@claude[bot]) — Style preference, not blocking.
• Bot summaries (@coderabbitai[bot], @greptile-apps[bot]) — Status posts, no action needed.

All review threads resolved.

@justin808 Thanks for the round 2 follow-up! The additional serverWebpackConfig.js assertions — mirroring the RSCWebpackPlugin import check and rscBundle parameter check from the --rsc context — are a solid improvement that ensures parity between the two modes. The rationale for keeping contexts self-contained is sensible; shared examples can always be introduced later if the number of RSC modes grows.

The PR looks good — all threads resolved and tests green. Approving.

[approve]

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/packages/react-on-rails-pro/**/*.test.rsc.{ts,tsx} : Pro RSC tests should be run with: `pnpm --filter react-on-rails-pro run test:rsc`

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/spec/dummy/commonWebpackConfig.js : Changes to `commonWebpackConfig.js` affect all three webpack bundles (client, server, and RSC) in the Pro dummy app

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/spec/dummy/*WebpackConfig.js : The Pro dummy app has three separate webpack configs: `clientWebpackConfig.js`, `serverWebpackConfig.js`, and `rscWebpackConfig.js`

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/**/*.ts : When editing RSC-related files, check if a `.rsc.ts` counterpart exists due to conditional package exports using the `react-server` condition

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/packages/react-on-rails-pro/**/*.test.{ts,tsx,js,jsx} : Pro JS tests should be run with: `pnpm --filter react-on-rails-pro run test`

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/spec/react_on_rails_pro/**/*.rb : Pro gem unit tests should be run with: `cd react_on_rails_pro && bundle exec rspec spec/react_on_rails_pro/`

Learnt from: AbanoubGhadban
Repo: shakacode/react_on_rails PR: 1644
File: lib/react_on_rails/helper.rb:190-197
Timestamp: 2025-02-18T13:08:01.477Z
Learning: RSC support validation in React on Rails Pro is handled through a chain of validations:
1. Pro version check in `run_stream_inside_fiber`
2. RSC support check during pack generation via `ReactOnRailsPro.configuration.enable_rsc_support`
3. RSC support validation during component registration
This makes additional validation in the helper methods unnecessary.

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/spec/dummy/spec/**/*.rb : Pro integration tests should be run with: `cd react_on_rails_pro/spec/dummy && bundle exec rspec spec/`

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/packages/react-on-rails-pro-node-renderer/**/*.test.{ts,tsx,js,jsx} : Node renderer tests should be run with: `pnpm --filter react-on-rails-pro-node-renderer run test`

Learnt from: justin808
Repo: shakacode/react_on_rails PR: 2610
File: docs/pro/react-server-components/create-without-ssr.md:13-22
Timestamp: 2026-03-24T21:38:26.825Z
Learning: In `docs/pro/react-server-components/create-without-ssr.md`, JS install instructions for React on Rails Pro should only install `react-on-rails-pro` (not `react-on-rails` separately), because the Pro package already includes the base package functionality. Use `--exact` (yarn/pnpm) or `--save-exact` (npm) flags to pin to an exact version for reproducibility.

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-02-24T16:52:47.694Z
Learning: Applies to react_on_rails_pro/**/*.config.{js,ts} : Pro server bundles are private in `ssr-generated/` directory with `enforce_private_server_bundles = true` setting

Review

Overall: This is a straightforward, low-risk addition. The missing test coverage for --rsc-pro is real and worth closing — the generator mode was fully implemented in #2822 but the test file only verified version pinning and DEFAULT_ROUTE. This PR correctly adds assertions for webpack config, node renderer, Procfile, and HelloServer scaffolding.

What looks good

• All 7 new it blocks are logically correct and test the right output.
• Assertions are well-scoped (negative + positive checks in the HelloServer test, regex for the rscBundle parameter).
• scriptSanitizedVal rename is a no-op refactor with a small debugging benefit (named functions appear in stack traces instead of <anonymous>).

One issue worth addressing before more RSC variants land

See the inline comment on lines 1735-1792. Every new it block is a near-verbatim copy of an existing test from the with --rsc context (lines 1552-1629). The tests are functionally correct, but the duplication will multiply as more RSC variants are added (--rsc --rspack already shares some of this territory). Extracting these into a rsc_webpack_and_renderer_files shared example would follow the existing pattern (rsc_common_files, rsc_hello_server_files) and eliminate the copy-paste.

Not blocking — the coverage is better than it was — but worth doing before the pattern spreads further.

Review of #3098 — Add comprehensive --rsc-pro generator tests

Good work closing the coverage gap on the --rsc-pro path. The assertions are accurate and the test plan looks solid. One substantive concern worth addressing before merge, plus a minor naming observation.

Code duplication — consider shared examples

Five of the seven new tests are character-for-character identical to tests already present in the --rsc context:

The codebase already does this right via rsc_generator_examples.rb — rsc_common_files and rsc_hello_server_files are used in both contexts. These five tests are the same behavioural contract and belong in the same file, perhaps as a new shared example like rsc_webpack_configuration:

# spec/react_on_rails/support/shared_examples/rsc_generator_examples.rb
shared_examples "rsc_webpack_configuration" do
  it "creates node-renderer.js" do ... end
  it "adds RSC bundle watcher to Procfile.dev" do ... end
  it "creates rscWebpackConfig.js" do ... end
  it "serverWebpackConfig includes RSCWebpackPlugin import" do ... end
  it "serverWebpackConfig has rscBundle parameter" do ... end
end

Then both contexts simply call include_examples "rsc_webpack_configuration". Without this, any future template change requires updating the same assertions in two places.

Minor: route test naming inconsistency

The new "adds HelloServer route and RSC payload route" name is actually more accurate than the --rsc counterpart ("adds HelloServer route") because both assert rsc_payload too. It would be worth updating the --rsc test name to match at the same time, or consolidate it into a shared example to enforce parity going forward.