Skip to content

chore: remove redundant --rsc-pro install generator flag#3105

Merged
ihabadham merged 5 commits intomainfrom
ihabadham/chore/remove-rsc-pro-flag
Apr 21, 2026
Merged

chore: remove redundant --rsc-pro install generator flag#3105
ihabadham merged 5 commits intomainfrom
ihabadham/chore/remove-rsc-pro-flag

Conversation

@ihabadham
Copy link
Copy Markdown
Collaborator

@ihabadham ihabadham commented Apr 10, 2026

Summary

#2821 introduced a dedicated --rsc-pro install flag. It was closed the next
day with: "Closing as redundant: current generator semantics already treat --rsc
as including Pro by design, so introducing --rsc-pro adds an unnecessary parallel
mode."

The flag then shipped anyway in #2822, which was primarily about the Pro upgrade
automation (#2626 — Gemfile swap, import rewriter). The --rsc-pro bits rode along
as a ~10% passenger in that larger PR and were never removed after #2821's close.

#3098 was then opened to add more tests for the flag, further entrenching
something that was explicitly called redundant.

This PR completes the intent behind #2821's close: removes the flag and folds
its useful behaviors into --rsc, where they belong.

What moves from --rsc-pro to --rsc

  • Pro verification checklist now fires on any --rsc install
  • Prerelease installation note now fires on any --rsc install with a prerelease
    gem version
  • Exact version pin for the Pro gem now triggers on
    Gem::Version.new(ReactOnRails::VERSION).prerelease? instead of the flag —
    this is the real reason exact pinning matters (Bundler's ~> doesn't match
    prereleases), not a flag-specific behavior

Side effect: plain --rsc on a prerelease gem version now installs correctly
where it previously would have failed against ~> pinning.

What is removed

  • class_option :rsc_pro
  • use_rsc_pro_mode? helper
  • --rsc-pro branches in use_pro?, use_rsc?, pro_requirement_flag,
    recovery_install_command
  • All --rsc-pro test contexts

What is NOT touched

pro_generator.rb and pro_generator_spec.rb (the #2626 upgrade automation —
Gemfile swap, import rewriter) are independent of this flag and untouched. Bugs
in that code are tracked separately in #3104.

Closes / supersedes

Supersedes #3098 (its test assertions were inside context "with --rsc-pro",
which no longer exists).

Test plan

  • bundle exec rubocop on all modified files — clean
  • CI to run the full rspec suite

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Removed

    • The Pro-specific install flag --rsc-pro has been removed.
  • Changed

    • Pro-related behaviors that previously required --rsc-pro now apply when using --rsc (post-install verification checklist, prerelease install notes, and exact Pro gem pinning for prereleases).
  • Chore

    • Added a URL exclusion to link-checking configuration to skip a specific domain.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 10, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

Removed the --rsc-pro install flag and consolidated its behaviors under --rsc; deleted use_rsc_pro_mode?; updated use_pro? / use_rsc?, pro/prerelease install logic, post-install messaging, tests, CHANGELOG, and a Lychee URL exclusion.

Changes

Cohort / File(s) Summary
Changelog
CHANGELOG.md
Added Unreleased → Removed entry documenting removal of the Pro-only --rsc-pro flag and consolidation of its behaviors into --rsc (verification checklist, prerelease note, exact prerelease gem pinning).
Generator helpers
react_on_rails/lib/generators/react_on_rails/generator_helper.rb
Removed use_rsc_pro_mode?. Updated use_pro? to `options[:pro]
Install generator
react_on_rails/lib/generators/react_on_rails/install_generator.rb
Removed --rsc-pro class option and related descriptions. Post-install verification now gated by use_rsc?. recovery_install_command no longer emits --rsc-pro and helper renamed from rsc_pro_verification_messagersc_verification_message.
Pro setup / prerelease logic
react_on_rails/lib/generators/react_on_rails/pro_setup.rb
Removed rsc_pro gating for prerelease messaging and gem selection. Introduced prerelease_ror_version? (Gem::Version‑based with ArgumentError handling). pro_requirement_flag returns --rsc when options[:rsc]; exact gem pinning now controlled by prerelease detection.
Generator helper tests
react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb
Removed tests for use_rsc_pro_mode?; added/updated assertions focusing on use_rsc? and use_pro? across rsc: true, pro: true, and both-false scenarios.
Install generator tests
react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb
Removed --rsc-pro contexts and many related assertions. Updated expectations to use --rsc (including recovery command and Pro verification message). Added prerelease ReactOnRails::VERSION scenario asserting exact pro gem pin and prerelease note. Removed tests that treated --rsc-pro as a distinct combined mode.
Link checker config
.lychee.toml
Added exclusion regex '^https://(www\.)?guavapass\.com' to skip link checks to that domain.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 A flag that hopped as two now bounds as one,
--rsc leads the meadow, shining like the sun.
Gems snugly pinned when prereleases bloom,
Tests and notes hopped tidy through the room.
Carrots saved — a tidy patch for everyone! 🥕

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 21.43% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately and specifically describes the main change: removing the redundant --rsc-pro flag from the install generator.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch ihabadham/chore/remove-rsc-pro-flag

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 10, 2026

Review: chore: remove redundant --rsc-pro install generator flag

The intent is clear and the mechanics are correct — collapsing --rsc-pro into --rsc is the right call. A few issues worth addressing before merge:

Behavioral gap: rsc_prerelease_note is gated on use_rsc? but exact pinning now applies to all Pro installs

pro_gem_version_requirement correctly uses prerelease_ror_version? to trigger exact pinning for any prerelease version regardless of flags. But rsc_prerelease_note is still gated on use_rsc?:

def rsc_prerelease_note
  return "" unless use_rsc?          # <-- too narrow
  return "" unless prerelease_ror_version?
  ...
end

A user running --pro (without --rsc) on a prerelease ReactOnRails::VERSION will now silently get an exact version pin with no explanatory note. The note text ("may not be published yet — use a local path: option") applies equally to --pro prerelease installs. The guard should be return "" unless use_pro? (or drop it entirely and keep only the prerelease_ror_version? guard), and the method should probably be renamed to prerelease_note since it no longer has any RSC-specific meaning.

Stale method name: rsc_pro_verification_message

install_generator.rb:507 still defines a method named rsc_pro_verification_message even though it now fires on any --rsc install. Rename to rsc_verification_message (or rsc_post_install_message) to match the new semantics.

Missing test coverage

There is no test for --pro + prerelease version:

  • Verifying that exact pinning triggers (the new behaviour of pro_gem_version_requirement)
  • Verifying that a note is shown (once the guard above is fixed)

CHANGELOG URL

The CHANGELOG entry links to PR 3104 with an /issues/ URL:

[PR 3104](https://github.com/shakacode/react_on_rails/issues/3104)

Should be /pull/3104. GitHub redirects silently, but the mislabelled path is inconsistent with the two other PR links in the same sentence that use /pull/.


The core removal is solid. The guard narrowing in rsc_prerelease_note is the most important fix — it leaves a silent correctness gap for --pro prerelease installs.

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented Apr 10, 2026

Greptile Summary

This PR removes the --rsc-pro install generator flag and folds its useful behaviors into --rsc, which already implies Pro by design. The removal is clean: use_rsc_pro_mode? and class_option :rsc_pro are deleted, the prerelease exact-pin logic is moved to prerelease_ror_version? (a better semantic trigger than a flag), and the RSC Pro verification checklist now fires for all --rsc installs. Tests are updated to match the new behavior.

Confidence Score: 5/5

Safe to merge — no regressions introduced; all behavioral changes are intentional and well-tested.

All findings are P2 or lower. The flag removal is complete and consistent across options declaration, helper methods, install logic, pro setup, and tests. The prerelease exact-pin logic is now correctly driven by gem version semantics rather than a flag. Test coverage is maintained for all affected paths.

No files require special attention.

Important Files Changed

Filename Overview
react_on_rails/lib/generators/react_on_rails/generator_helper.rb Removes use_rsc_pro_mode? helper and simplifies use_pro?/use_rsc? to check only :pro/:rsc options — clean and correct
react_on_rails/lib/generators/react_on_rails/install_generator.rb Removes class_option :rsc_pro, updates add_post_install_message to use use_rsc? and cleans up recovery_install_command — all branches handled correctly
react_on_rails/lib/generators/react_on_rails/pro_setup.rb pro_gem_version_requirement now triggers exact pinning on prerelease_ror_version? rather than a flag — semantically correct fix; rsc_prerelease_note only fires when use_rsc? is true
react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb Removes --rsc-pro test contexts, replaces the combined prerelease+exact-pin test with a single --rsc+prerelease context, and updates the no-flags context to drop rsc_pro: false — coverage is maintained
react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb No functional changes to the spec; existing helper tests remain intact and relevant
CHANGELOG.md Changelog entry is thorough and accurately describes all behavioral changes introduced by this PR

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[rails generate react_on_rails:install] --> B{Which flags?}
    B -->|--rsc| C[use_rsc? = true\nuse_pro? = true]
    B -->|--pro| D[use_rsc? = false\nuse_pro? = true]
    B -->|neither| E[use_rsc? = false\nuse_pro? = false]

    C --> F{prerelease_ror_version?}
    F -->|yes| G["pro_gem_version_requirement\n= ReactOnRails::VERSION (exact pin)"]
    F -->|no| H["pro_gem_version_requirement\n= '~> X.Y.Z' (pessimistic)"]

    C --> I[add_post_install_message]
    I --> J["rsc_pro_verification_message\n(always fires for --rsc)"]

    C --> K["rsc_prerelease_note\n(fires if prerelease)"]

    D --> L{prerelease_ror_version?}
    L -->|yes| M["exact pin (no prerelease note\nsince use_rsc? = false)"]
    L -->|no| N["~> pin"]
Loading

Reviews (1): Last reviewed commit: "chore: remove --rsc-pro install generato..." | Re-trigger Greptile

Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb Outdated
Comment thread react_on_rails/lib/generators/react_on_rails/install_generator.rb Outdated
Comment thread CHANGELOG.md Outdated
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
react_on_rails/lib/generators/react_on_rails/install_generator.rb (1)

476-485: ⚠️ Potential issue | 🟡 Minor

Successful prerelease --rsc installs still miss the prerelease guidance.

This is now the normal post-install path for --rsc, but it only adds the verification checklist. The prerelease note lives on the auto-install failure path, so a successful prerelease RSC install never shows the “may not be published yet / use a local path” guidance described in the PR goals.

Suggested follow-up
         GeneratorMessages.add_info(GeneratorMessages.helpful_message_after_installation(
                                      component_name: component_name,
                                      route: route,
                                      pro: use_pro?,
                                      rsc: use_rsc?,
                                      shakapacker_just_installed: shakapacker_just_installed?,
                                      landing_page: options.new_app? && new_app_root_route_available?
                                    ))
-        GeneratorMessages.add_info(rsc_pro_verification_message) if use_rsc?
+        if use_rsc?
+          GeneratorMessages.add_info(rsc_prerelease_note) unless rsc_prerelease_note.empty?
+          GeneratorMessages.add_info(rsc_pro_verification_message)
+        end
       end
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@react_on_rails/lib/generators/react_on_rails/install_generator.rb` around
lines 476 - 485, The post-install path for RSC only adds
rsc_pro_verification_message and omits the prerelease guidance that is shown on
the auto-install failure path; when use_rsc? is true and the install was a
prerelease RSC install, also add the same prerelease guidance message to the
successful path. Modify the block that calls
GeneratorMessages.add_info(...helpful_message_after_installation(...)) to, after
that call, check the prerelease condition (the same predicate used on the
auto-install failure path, e.g., rsc_prerelease? or equivalent) and call
GeneratorMessages.add_info(prerelease_rsc_message) (the same message object used
on the failure path) so successful prerelease installs display the “may not be
published yet / use a local path” guidance.
🧹 Nitpick comments (1)
react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb (1)

2805-2830: Add the matching prerelease pinning spec for --pro.

This example covers the RSC-only note, but the exact version pinning now comes from prerelease? itself rather than RSC mode. A sibling --pro prerelease case would keep the non-RSC path from regressing back to ~> pinning later.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb`
around lines 2805 - 2830, Add a new spec mirroring the prerelease RSC test but
for the --pro flag: instantiate described_class with pro: true (e.g.,
let(:install_generator) { described_class.new([], { pro: true }) }), stub
ReactOnRails::VERSION to a prerelease (e.g., "16.4.0.rc.5"), and assert
missing_pro_gem? still spawns bundle add with the exact prerelease version
string (check Process.spawn called with "bundle add react_on_rails_pro
--version='16.4.0.rc.5' --strict") and that GeneratorMessages contains the
prerelease guidance (checks for "gem 'react_on_rails_pro', '16.4.0.rc.5'", "may
not be published yet", and "path:"); this ensures prerelease? drives exact
pinning for the --pro path just like the --rsc case and prevents regression to
~> pinning.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@CHANGELOG.md`:
- Around line 27-30: Update the changelog entry describing the "Removed the
`--rsc-pro` install generator flag" to use the standard attribution format:
change the trailing reference to list Issue 3104 as "Issue 3104" (instead of "PR
3104") and append the actual PR attribution for the current change as "[PR
3105](https://github.com/shakacode/react_on_rails/pull/3105) by
[ihabadham](https://github.com/ihabadham)" so the line ends with the PR link and
author in the required "[PR NUMBER](url) by [username](url)" form while keeping
the inline **[Pro]** prefix and existing explanatory text intact.

---

Outside diff comments:
In `@react_on_rails/lib/generators/react_on_rails/install_generator.rb`:
- Around line 476-485: The post-install path for RSC only adds
rsc_pro_verification_message and omits the prerelease guidance that is shown on
the auto-install failure path; when use_rsc? is true and the install was a
prerelease RSC install, also add the same prerelease guidance message to the
successful path. Modify the block that calls
GeneratorMessages.add_info(...helpful_message_after_installation(...)) to, after
that call, check the prerelease condition (the same predicate used on the
auto-install failure path, e.g., rsc_prerelease? or equivalent) and call
GeneratorMessages.add_info(prerelease_rsc_message) (the same message object used
on the failure path) so successful prerelease installs display the “may not be
published yet / use a local path” guidance.

---

Nitpick comments:
In `@react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb`:
- Around line 2805-2830: Add a new spec mirroring the prerelease RSC test but
for the --pro flag: instantiate described_class with pro: true (e.g.,
let(:install_generator) { described_class.new([], { pro: true }) }), stub
ReactOnRails::VERSION to a prerelease (e.g., "16.4.0.rc.5"), and assert
missing_pro_gem? still spawns bundle add with the exact prerelease version
string (check Process.spawn called with "bundle add react_on_rails_pro
--version='16.4.0.rc.5' --strict") and that GeneratorMessages contains the
prerelease guidance (checks for "gem 'react_on_rails_pro', '16.4.0.rc.5'", "may
not be published yet", and "path:"); this ensures prerelease? drives exact
pinning for the --pro path just like the --rsc case and prevents regression to
~> pinning.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 585645f3-c5e5-4adf-9348-8cb36bccfac9

📥 Commits

Reviewing files that changed from the base of the PR and between 1595fb8 and b878fc7.

📒 Files selected for processing (6)
  • CHANGELOG.md
  • react_on_rails/lib/generators/react_on_rails/generator_helper.rb
  • react_on_rails/lib/generators/react_on_rails/install_generator.rb
  • react_on_rails/lib/generators/react_on_rails/pro_setup.rb
  • react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb
  • react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb

Comment thread CHANGELOG.md
The --rsc-pro flag was redundant with --rsc (which already implies Pro)
and was originally closed as an "unnecessary parallel mode" in #2821 before
shipping unintentionally alongside the Pro upgrade automation in #2822.

Fold the useful behaviors previously gated on --rsc-pro into --rsc:

- Pro verification checklist message now fires on any --rsc install
  instead of only when use_rsc_pro_mode? was true.
- Prerelease installation note (rsc_prerelease_note) now fires on any
  --rsc install with a prerelease gem version.
- Exact version pin for the Pro gem now triggers on
  Gem::Version.new(ReactOnRails::VERSION).prerelease? instead of the flag.
  This is the real underlying reason: Bundler's ~> does not match
  prerelease versions, so stable --rsc installs continue to use ~> while
  prerelease cycles get an exact pin that actually installs.

Side effect: plain --rsc on a prerelease gem version now installs
correctly where it previously would have failed against ~> pinning.

Removes:

- class_option :rsc_pro
- use_rsc_pro_mode? helper
- the --rsc-pro branches in use_pro?, use_rsc?, pro_requirement_flag,
  recovery_install_command
- all --rsc-pro test contexts in install_generator_spec and the
  RSC Pro mode helpers describe block in generator_helper_spec

Does not touch pro_generator.rb or pro_generator_spec.rb; those cover
the #2626 upgrade automation scope (independent of this flag), and the
silent-failure bugs there are tracked separately in #3104.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ihabadham ihabadham force-pushed the ihabadham/chore/remove-rsc-pro-flag branch from b878fc7 to 0d4481f Compare April 21, 2026 17:17
Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb Outdated
Comment thread react_on_rails/lib/generators/react_on_rails/install_generator.rb Outdated
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 21, 2026

Code Review

Overall: clean, well-scoped change. The PR does exactly what it says — removes a flag that was explicitly called redundant at close time and folds its behaviors into --rsc. The diff is easy to follow, the test updates are thorough, and the CHANGELOG entry is accurate.

Issues

1. Stale method name (inline comment posted): rsc_pro_verification_message in install_generator.rb retains the removed flag's name. Renaming it to rsc_verification_message is a one-liner with no logic change.

2. Silent exact-pinning for --pro on prerelease versions (inline comment posted): pro_gem_version_requirement now applies exact version pinning for all Pro installs when ReactOnRails::VERSION is a prerelease, not just --rsc. That's the right call — ~> genuinely doesn't match prereleases regardless of flag. But rsc_prerelease_note is still gated on use_rsc?, so a user running --pro on a prerelease gem gets the exact pin silently with no explanation of why bundle add uses '16.x.y.rc.N' instead of '~> 16.x'. Either drop the use_rsc? guard, or add a comment explaining why the note is intentionally RSC-only.

3. Missing test for --pro alone on prerelease version: The new test context (line 2977) covers --rsc + prerelease. There is no parallel test for --pro alone + prerelease, which is now also subject to exact pinning. Adding a context block mirroring the existing one with described_class.new([], { pro: true }) would pin the behavior.

Observations / non-blocking

  • The prerelease_ror_version? extraction with its own ArgumentError rescue is cleaner than the inlined rescue in the old rsc_pro_prerelease_note — good separation.
  • Removing the two --rsc-pro sub-generator delegation tests is correct; the same paths are exercised by the existing --rsc --pro test context (line 2296).
  • The PR description is unusually detailed and accurate — the parenthetical about --rsc + prerelease now installing correctly where it previously failed is a real side-effect worth keeping in the CHANGELOG.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0d4481f8e0

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb Outdated
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb (1)

2977-3002: ⚠️ Potential issue | 🟡 Minor

Add --pro prerelease coverage or stabilize the existing --pro spec.

Line 540 now exact-pins prereleases for all Pro installs, not only --rsc. The nearby --pro missing-gem spec still depends on the repository’s current ReactOnRails::VERSION and expects a ~> requirement, so it can fail during a prerelease cycle unless that example stubs a stable version or a separate --pro prerelease example asserts the exact pin.

Proposed spec hardening
 context "when using --pro flag without Pro gem installed" do
   let(:install_generator) { described_class.new([], { pro: true }) }
-  let(:expected_pro_version) { Gem::Version.new(ReactOnRails::VERSION).release.to_s }
+  let(:stable_ror_version) { "16.4.0" }
+  let(:expected_pro_version) { stable_ror_version }
   let(:fake_pid) { 12_345 }

   before do
+    stub_const("ReactOnRails::VERSION", stable_ror_version)
     allow(Gem).to receive(:loaded_specs).and_return({})
     allow(install_generator).to receive(:gem_in_lockfile?).with("react_on_rails_pro").and_return(false)
     allow(Bundler).to receive(:with_unbundled_env).and_yield
     allow(Process).to receive(:spawn).and_return(fake_pid)
     allow(install_generator).to receive(:wait_for_bundle_process)
       .with(fake_pid).and_return(instance_double(Process::Status, success?: false))
   end
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb`
around lines 2977 - 3002, The existing --pro spec can fail during a prerelease
cycle because ReactOnRails::VERSION is currenty a prerelease; update the spec(s)
around missing_pro_gem? in react_on_rails/generators/install_generator_spec.rb
so they are deterministic: either (A) stabilize the existing --pro example by
stubbing ReactOnRails::VERSION to a non-prerelease string (e.g. "16.4.0") before
invoking install_generator.send(:missing_pro_gem?) or (B) add a new context that
simulates a prerelease (stub_const("ReactOnRails::VERSION", "16.4.0.rc.5")) and
assert the exact-version pin used by missing_pro_gem? (expect Process.spawn to
be called with --version='16.4.0.rc.5' and the resulting GeneratorMessages to
mention the exact pin), leaving the original --pro spec unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb`:
- Around line 2977-3002: The existing --pro spec can fail during a prerelease
cycle because ReactOnRails::VERSION is currenty a prerelease; update the spec(s)
around missing_pro_gem? in react_on_rails/generators/install_generator_spec.rb
so they are deterministic: either (A) stabilize the existing --pro example by
stubbing ReactOnRails::VERSION to a non-prerelease string (e.g. "16.4.0") before
invoking install_generator.send(:missing_pro_gem?) or (B) add a new context that
simulates a prerelease (stub_const("ReactOnRails::VERSION", "16.4.0.rc.5")) and
assert the exact-version pin used by missing_pro_gem? (expect Process.spawn to
be called with --version='16.4.0.rc.5' and the resulting GeneratorMessages to
mention the exact pin), leaving the original --pro spec unchanged.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 09168e2f-f04d-4067-a255-e4c0236e4b81

📥 Commits

Reviewing files that changed from the base of the PR and between b878fc7 and 0d4481f.

📒 Files selected for processing (6)
  • CHANGELOG.md
  • react_on_rails/lib/generators/react_on_rails/generator_helper.rb
  • react_on_rails/lib/generators/react_on_rails/install_generator.rb
  • react_on_rails/lib/generators/react_on_rails/pro_setup.rb
  • react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb
  • react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb
✅ Files skipped from review due to trivial changes (2)
  • react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb
  • CHANGELOG.md
🚧 Files skipped from review as they are similar to previous changes (1)
  • react_on_rails/lib/generators/react_on_rails/generator_helper.rb

The guavapass.com link in PROJECTS.md consistently fails the lychee
link check from GitHub Actions runners with a TLS handshake error,
even though the site is reachable from other networks. This is a
bot-filter at the site's TLS layer blocking the runner IP range.

Adds an exclusion matching the established pattern for other
PROJECTS.md links that block automated requests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 21, 2026

Code Review: Remove redundant --rsc-pro install generator flag

Overall: This is a clean, well-motivated cleanup. The logic is correct — --rsc already implies Pro, so --rsc-pro was genuinely redundant. The diff is structured clearly, the rationale in the PR description is thorough, and the net result (−176 lines) is a real simplification.

A few issues worth addressing:


Bug / Regression risk

rsc_prerelease_note no longer fires for --pro on a prerelease version

pro_gem_version_requirement now uses exact pinning for all prerelease versions (regardless of --rsc vs --pro), which is correct. But rsc_prerelease_note still gates on use_rsc?:

def rsc_prerelease_note
  return "" unless use_rsc?   # ← skipped when --pro is used alone
  ...
end

A user who runs --pro against a prerelease gem will get an exact pin in the Gemfile with no explanation. The note should fire on prerelease_ror_version? alone, not use_rsc? && prerelease_ror_version?. Since the prerelease note is now version-driven rather than flag-driven, the use_rsc? guard should be dropped.


Naming inconsistency (stale "rsc_pro" label)

rsc_pro_verification_message (in install_generator.rb) still carries the old flag name in its identifier even though --rsc-pro is gone. The method and its call site should be renamed to rsc_verification_message to match the new semantics.


Missing test: --pro + prerelease exact pin

There is a test verifying --rsc + prerelease produces an exact pin and a note ("missing_pro_gem? uses exact version pin and surfaces a prerelease note"). There is no corresponding test verifying that --pro + prerelease version also produces an exact pin (without the note). Given that this PR changes pro_gem_version_requirement to be version-driven for all flags, a --pro prerelease test would make that guarantee explicit.


Minor: inconsistent RSpec matcher style

generator_helper_spec.rb uses be_falsey in the new "plain install" test but be(false) in the two tests above it. Prefer be(false) for explicitness (matches the rest of the describe block).


What's good

  • The ArgumentError rescue is correctly moved from rsc_prerelease_note into prerelease_ror_version?, giving it a single home.
  • recovery_install_command correctly drops the --rsc-pro--rsc fallthrough without introducing dead branches.
  • Removing the --rsc-pro integration test context is the right call — the behaviour is fully covered by the existing --rsc context.
  • The .lychee.toml addition is unrelated but harmless.

Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb Outdated
Comment thread react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb Outdated
Comment thread react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb Outdated
- pro_setup.rb: rename `rsc_prerelease_note` to `prerelease_note` and
  gate on `prerelease_ror_version?` instead of `use_rsc?`. The exact
  version pin in `pro_gem_version_requirement` already fires on any
  prerelease regardless of flag; the explanatory note should match so
  a `--pro` user on a prerelease gem sees the same "may not be published
  yet" context a `--rsc` user gets. Dropped the intermediate local
  variable that clashed with the renamed method.

- install_generator.rb: rename `rsc_pro_verification_message` to
  `rsc_verification_message` at both the call site and the definition.
  The method now fires on any `use_rsc?` install; the `_pro_` in the
  identifier was a stale reference to the removed flag. Heading text
  ("🔎 RSC Pro Verification") unchanged — --rsc implies Pro, so the
  content description is still accurate.

- CHANGELOG.md: restore cross-reference to the silent-failure bugs
  issue with correct label. The previous label said "[PR 3104]" even
  though the URL pointed to /issues/; both reviewers flagged the
  inconsistency. Now labeled "[Issue 3104]" with the same URL.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ihabadham
Copy link
Copy Markdown
Collaborator Author

Address-review summary

Scan scope: full PR history (no prior summary comment).

Mattered

  • Prerelease note gate too narrow (claude[bot] ×3, chatgpt-codex-connector[bot]): addressed in f867f94. Renamed rsc_prerelease_noteprerelease_note and gated on prerelease_ror_version? instead of use_rsc? so the note fires whenever the exact pin fires, including for --pro on a prerelease gem.
  • Stale method name rsc_pro_verification_message (claude[bot] ×2): addressed in f867f94. Renamed method + call site to rsc_verification_message. Heading text "🔎 RSC Pro Verification" kept — it accurately describes what's being verified.
  • CHANGELOG link label (coderabbitai[bot] correct, claude[bot] ×1 incorrect): addressed in f867f94. Labeled as [Issue 3104] while keeping the /issues/3104 URL (3104 is an issue, not a PR). Declined claude[bot]'s suggestion to change the URL to /pull/3104 since that would be broken.

Optional

  • Missing --pro + prerelease test context (claude[bot]): declined. Existing --rsc + prerelease test covers the pro_gem_version_requirement code path; a parallel --pro test is defense-in-depth but would largely duplicate coverage.
  • be_falsey vs be(false) matcher consistency (claude[bot] ×2): declined. For the test as written (options explicitly stubbed with rsc: false, pro: false), both matchers behave identically.

Skipped

  • None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 21, 2026

Code Review

Overview

Clean, well-motivated removal of the redundant --rsc-pro flag. Core logic improvements (prerelease pinning keyed on the actual version, extracted prerelease_ror_version? helper with rescue ArgumentError in one place) are good refactors.

Issues

1. New behavior for --pro alone on prerelease versions is untested

pro_gem_version_requirement and prerelease_note now trigger for any Pro install (including --pro alone) when the version is a prerelease. Before this PR both were gated on use_rsc_pro_mode?. This is a correct fix, but the only new test covers --rsc. A companion test for --pro + prerelease would close the coverage gap.

2. Removed --rsc-pro context had a unique npm version-pin assertion

The deleted context verified exact npm version strings for react-on-rails-pro, react-on-rails-pro-node-renderer, and react-on-rails-rsc. The existing context "with --rsc" (line 1578 of the spec) only checks key presence. Worth porting those version-string assertions into the --rsc context to catch regressions in JsDependencyManager or VersionSyntaxConverter.

3. Breaking change: no in-code migration path for --rsc-pro

After this PR, passing --rsc-pro produces a Thor "invalid option" error with no hint about what to use instead. The flag shipped in a released gem. A one-liner printing a friendly redirect would be low-cost. Not a blocker if the project prefers a clean break, but worth a deliberate decision.

Nits

  • Double blank line (see inline comment on pro_setup.rb): when prerelease_note returns "", the heredoc in missing_pro_gem? produces two consecutive blank lines. Pre-existing, but easy to fix now.
  • be_falsey vs be(false) (see inline comment on generator_helper_spec.rb): inconsistent with the other expectations in the same block; be(false) is more precise.

Summary

The simplification is sound and well-scoped. Main asks before merging: (1) add a prerelease test for --pro alone, and (2) decide on migration message vs. clean break for existing --rsc-pro users.

Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb Outdated
Comment thread react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb Outdated
- pro_setup.rb: skip the prerelease-note line entirely when
  `prerelease_note` returns an empty string. The old interpolation
  left two consecutive blank lines in the error message on stable
  versions (the common case) because an empty `#{prerelease_note}`
  still consumed its heredoc line. Pre-compute an `optional_prerelease_line`
  that is either `""` or a leading newline plus the note, and append
  it to the preceding context line.

- install_generator_spec.rb: strengthen the `--rsc` npm-dependency
  assertion from key presence to exact version-string pins. The
  deleted `--rsc-pro` context verified the exact `react-on-rails-pro`
  / `react-on-rails-pro-node-renderer` / `react-on-rails-rsc` npm
  versions; those assertions are now carried into the surviving
  `--rsc` context so regressions in `JsDependencyManager`
  or `VersionSyntaxConverter` remain covered at the integration level.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ihabadham
Copy link
Copy Markdown
Collaborator Author

Thanks @claude, addressing each point:

Issue 1 (--pro + prerelease test): declined. The --rsc + prerelease test already exercises pro_gem_version_requirement and prerelease_ror_version? through the same code path; a parallel --pro test would largely duplicate that coverage. Unit coverage for JsDependencyManager version pinning lives in js_dependency_manager_spec.rb.

Issue 2 (npm version-pin assertions): addressed in f7c161a. Strengthened the --rsc context's installs RSC npm dependencies test from key-presence to exact version-string pins — the same assertions the deleted --rsc-pro context carried.

Issue 3 (friendly migration message for --rsc-pro): skipping. The flag only shipped in 16.6.0 (~2 weeks ago), real-world adoption is negligible, and the generic Thor error is adequate. Deliberate clean break.

Nits:

  • Double blank line: addressed in f7c161a (see inline thread).
  • be_falsey vs be(false): left as-is, see inline thread — matchers are equivalent for this stubbed test.

@ihabadham
Copy link
Copy Markdown
Collaborator Author

Address-review summary

Scan scope: review activity after 2026-04-21T18:20:41Z (previous summary).

Mattered

  • Breaking-change UX / migration message for --rsc-pro (claude[bot]): declined. The flag only shipped in 16.6.0 (~2 weeks ago) so adoption is negligible; a clean break with the generic Thor error is adequate.

Optional

  • Double blank line in missing_pro_gem? error message (claude[bot]): addressed in f7c161a. Pre-computed optional_prerelease_line to avoid the empty-interpolation-on-its-own-line pattern.
  • Port npm version-pin assertions to --rsc context (claude[bot]): addressed in f7c161a. Strengthened the surviving --rsc test from key-presence to exact version-string pins using ReactOnRails::VersionSyntaxConverter and RSC_PACKAGE_VERSION_PIN.

Skipped

  • coderabbitai acknowledgment (3119517748): auto-reply on an already-resolved CHANGELOG thread confirming the fix — no action needed.
  • be_falsey vs be(false) re-raised (3119530989): duplicate of a style nit declined earlier this cycle; matchers behave identically for this explicitly-stubbed test. Replied and resolved.
  • Missing --pro + prerelease test (in claude[bot] review 4290857020): duplicate of an optional item declined in the previous cycle. Folded the rationale into the general reply.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

Comment thread react_on_rails/spec/react_on_rails/generators/generator_helper_spec.rb Outdated
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 21, 2026

Code Review

Overview: This PR removes the --rsc-pro install generator flag and folds its behaviors into --rsc. The motivation is sound: --rsc-pro was explicitly called redundant when its companion PR was closed, but shipped anyway as a bystander in a larger PR.

What works well:

  1. Correct abstraction for prerelease pinning. Moving the exact version pin from use_rsc_pro_mode? to prerelease_ror_version? is a genuine bug fix. Bundler ~> does not match prerelease versions, so the exact pin was always needed for any prerelease install, not just --rsc-pro. The new helper with its rescue ArgumentError => false is in exactly the right place.

  2. Cleaner message formatting. The old code always emitted a blank line from the prerelease_note interpolation even when the note was empty. The new optional_prerelease_line conditional fixes that.

  3. Dirty-worktree coverage retained. The removed --rsc-pro dirty-worktree context was already covered by the existing --rsc equivalent at line 3135 -- no coverage gap.

  4. Test specificity improved. The updated npm-dependencies test now asserts exact version pins rather than just key presence.

Issues / suggestions:

Minor nit (inline comment posted): be_falsey in the plain-install test is inconsistent with be(true) / be(false) in the surrounding examples. Since option values are strict booleans, be(false) is more precise.

Implicit --rsc --pro combo behaviour. Previously, passing both --rsc and --pro triggered use_rsc_pro_mode? = true, with downstream effects (exact pinning, verification checklist, recovery command). After this PR the combo is silently treated as plain --rsc. There is no test asserting this, and the CLI description no longer mentions the interaction. A brief note in the --rsc option description would help:

desc: 'Install React Server Components support (includes Pro; --pro is redundant with --rsc). Default: false'

Summary: Clean, well-motivated removal. The behavioural changes are genuine improvements (prerelease fix, no spurious blank line), test coverage is maintained, and the diff is easy to follow. The be_falsey nit and the --rsc --pro documentation gap are both minor.

Replace `be_falsey` with `be(false)` in the plain-install test.
The repo uses `be(false)` / `be(true)` ~45 times across the spec
tree versus only 2 uses of `be_falsey` (both introduced by this PR),
so `be_falsey` was an outlier. `be(false)` is also more precise —
it fails on `nil` returns that `be_falsey` would pass silently.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ihabadham
Copy link
Copy Markdown
Collaborator Author

Thanks @claude for the re-review. Addressing each point:

be_falsey inconsistency: addressed in ec61e4d. Confirmed via broader pattern scan (be(false) used ~45× in spec tree vs be_falsey 2× — both were mine from this PR), then aligned to the majority convention.

--rsc --pro combo documentation gap: skipping. The existing --rsc description already says "(includes Pro)", which implicitly tells users --pro is redundant with it. Adding an explicit "--pro is redundant with --rsc" clause is belt-and-suspenders wording for a combination few users will type. The behavior is correct (both flags silently resolve to the same install path); the help text stays concise.

@ihabadham
Copy link
Copy Markdown
Collaborator Author

Address-review summary

Scan scope: review activity after 2026-04-21T18:45:29Z (previous summary).

Mattered

  • None.

Optional

  • be_falseybe(false) style alignment (claude[bot]): addressed in ec61e4d. Verified the broader pattern first — be(false)/be(true) used ~45× in the spec tree vs be_falsey used 2× (both from this PR). Aligned to majority convention; be(false) is also stricter (fails on unintended nil returns).
  • --rsc --pro combo documentation gap (claude[bot] review 4290996603): declined. Existing --rsc description already says "(includes Pro)", implicitly conveying that --pro is redundant with it. Adding an explicit "--pro is redundant with --rsc" clause is belt-and-suspenders for a combination few users will type.

Skipped

  • None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@claude
Copy link
Copy Markdown
Contributor

claude Bot commented Apr 21, 2026

Code Review

Overall: Clean, well-motivated removal. The PR correctly identifies that --rsc-pro was redundant and does a thorough job of eliminating it without orphaning any code. The test coverage update is solid. A few things worth calling out:

What works well

  • prerelease_ror_version? is correctly extracted as a predicate and the rescue ArgumentError is in the right place now (in the predicate, not scattered in callers).
  • Removing use_rsc_pro_mode? simplifies the logic — there are now two orthogonal axes (use_pro?, use_rsc?) instead of three.
  • The rsc_common_files and rsc_hello_server_files shared examples already covered everything in the old --rsc-pro context, so the test deletions don't leave gaps.
  • Version-based pinning (prerelease_ror_version?) is more semantically correct than flag-based pinning.

Issues

Undocumented behavioral expansion in pro_gem_version_requirement / prerelease_note

Previously, exact version pinning and the prerelease note were gated on use_rsc_pro_mode? — meaning they only fired for --rsc-pro or --rsc --pro. Now pro_gem_version_requirement and prerelease_note fire for any Pro install (--pro alone included) when the version is a prerelease. This is the correct behavior (the prerelease issue is not RSC-specific), but:

  • The PR description only mentions "--rsc installs" getting these behaviors, not --pro alone.
  • There is no test asserting that --pro alone on a prerelease version uses exact pinning.

This is probably intentional — if so, please update the PR description and add a test for --pro + prerelease.

Missing stable-version pinning test

After this PR, --rsc on a stable gem version should use ~> x.y.z (pessimistic) rather than exact. The existing "installs RSC npm dependencies with matched version pins" test only verifies the NPM side (which uses the current version regardless). There is no test asserting that pro_gem_version_requirement returns "~> ..." for a stable --rsc install. Consider adding:

context "when using --rsc flag with a stable ReactOnRails version" do
  let(:install_generator) { described_class.new([], { rsc: true }) }
  before { stub_const("ReactOnRails::VERSION", "16.3.0") }

  specify "uses pessimistic pinning for the Pro gem" do
    expect(install_generator.send(:pro_gem_version_requirement)).to eq("~> 16.3.0")
  end
end

recovery_install_command test removes a useful negative assertion

The removed line:

expect(command).not_to match(/\s--rsc(\s|$)/)

was guarding against --rsc appearing as a standalone flag when --rsc-pro was in use. The intent was different (avoid duplication), but a simpler version of this assertion is still worth keeping to catch regressions where both --rsc and --pro end up in the command independently:

expect(command).not_to include("--pro")   # --rsc already implies Pro; no separate --pro flag

This line is already present — so this is fine, just noting the intent was already covered.

.lychee.toml: guavapass.com exclusion

The exclusion is pragmatic (CI bot-filter TLS failure), but guavapass.com is a legitimate customer reference in PROJECTS.md. It might be worth manually verifying the URL still resolves to the right page before permanently suppressing the check — if the site is dead, the reference should be removed rather than silenced.

Minor

  • rsc_verification_message (renamed from rsc_pro_verification_message) still emits "RSC Pro Verification:" as the header text. That's fine since --rsc implies Pro, but it could confuse a user who ran --rsc without realizing Pro was implied — could say "RSC + Pro Verification:" for clarity.

Comment thread react_on_rails/lib/generators/react_on_rails/pro_setup.rb
@ihabadham
Copy link
Copy Markdown
Collaborator Author

Thanks @claude. Going through each point:

PR description accuracy — skipping. The behavior is correct (exact pin fires on prerelease regardless of flag); the description wording is slightly narrower than reality but not misleading.

Missing --pro + prerelease test — declined (see inline thread). Same code path as the existing --rsc prerelease test since the gate is version-based, not flag-based.

Missing stable-version pinning test — skipping. Tests the opposite branch of pro_gem_version_requirement, which would be genuine coverage. Accepting the gap; a future regression on the ~> branch would surface quickly since it's the default case for any Pro install on a stable version.

recovery_install_command note — no action needed, you noted the intent was already covered by expect(command).not_to include("--pro").

guavapass.com exclusion — already verified earlier in this cycle. Site responds HTTP 200 from non-CI hosts; the TLS handshake failure is specific to GitHub Actions IPs (bot filter). The reference in PROJECTS.md is to a legitimate customer, so the exclusion is the correct fix over removing the link.

@ihabadham
Copy link
Copy Markdown
Collaborator Author

Address-review summary

Scan scope: review activity after 2026-04-21T18:59:05Z (previous summary).

Mattered

  • None.

Optional

  • PR description accuracy (claude[bot]): declined. Behavior is correct (exact pin fires on prerelease regardless of flag); description wording is slightly narrower than reality but not misleading.
  • Missing --pro + prerelease test (claude[bot]): declined. Third raising of this. The gate is prerelease_ror_version? (version-based, not flag-based), so a --pro + prerelease test exercises the same conditional as the existing --rsc + prerelease test.
  • Missing stable-version pinning test (claude[bot]): declined. Would test the opposite branch of pro_gem_version_requirement; real coverage gap but accepted for velocity — the ~> branch is the default case so a regression would surface quickly in practice.

Skipped

  • recovery_install_command negative assertion (claude[bot]): non-actionable; reviewer confirmed the intent was already covered.
  • guavapass.com exclusion verification (claude[bot]): already verified earlier — site responds HTTP 200 from non-CI hosts; TLS handshake fails only from GitHub Actions IP range (bot filter). Exclusion is the correct fix for a legitimate PROJECTS.md customer reference.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

@ihabadham ihabadham merged commit efe3503 into main Apr 21, 2026
30 checks passed
@ihabadham ihabadham deleted the ihabadham/chore/remove-rsc-pro-flag branch April 21, 2026 19:09
justin808 added a commit that referenced this pull request Apr 23, 2026
…ons-docs

* origin/main:
  chore: remove redundant --rsc-pro install generator flag (#3105)
  ci: warn (don't fail) on Bencher main regression (#3168)
  test: enable RSpec --profile to surface slowest package tests (#3176)
  fix(node-renderer): expose performance in VM context when supportModules (#3158)
  docs: remove stale immediate_hydration references (#3139) (#3159)
  docs: restore absolute URL for node-renderer testing example (#3179)
  Bump Rspack dependencies to v2 (^2.0.0-0) (#3084)
  chore: remove obsolete webpack <5.106.0 pin (#3175)
  Move Node Renderer entry point to renderer/ directory (#3165)
  docs: address RSC pitfalls review follow-ups (#3155) (#3156)
  docs: remove fabricated DevConsole reference, link verified RSC tools (#2527) (#3163)

# Conflicts:
#	docs/oss/building-features/node-renderer/js-configuration.md
justin808 added a commit that referenced this pull request Apr 23, 2026
…ging' into jg/3122-rolling-deploy-adapter

* origin/jg/3122-unify-renderer-cache-staging: (39 commits)
  fix(specs): boot dummy specs without readline and drop redundant pnpm workspace (#3190)
  docs: add RSC migration success stories page (#1985) (#3162)
  Fix Bencher reporting permanently broken on pushes to main (#3148)
  docs: add example migrations guide (#3126)
  docs: remove defunct guavapass.com reference (#3199)
  chore: remove redundant --rsc-pro install generator flag (#3105)
  ci: warn (don't fail) on Bencher main regression (#3168)
  test: enable RSpec --profile to surface slowest package tests (#3176)
  fix(node-renderer): expose performance in VM context when supportModules (#3158)
  docs: remove stale immediate_hydration references (#3139) (#3159)
  docs: restore absolute URL for node-renderer testing example (#3179)
  Bump Rspack dependencies to v2 (^2.0.0-0) (#3084)
  chore: remove obsolete webpack <5.106.0 pin (#3175)
  Move Node Renderer entry point to renderer/ directory (#3165)
  docs: address RSC pitfalls review follow-ups (#3155) (#3156)
  docs: remove fabricated DevConsole reference, link verified RSC tools (#2527) (#3163)
  Scaffold CI workflow and build scripts for first-run consistency (#3097)
  Add OPTIONAL triage tier and fix recommendations to /address-review (#3161)
  chore: sync Gemfile.lock with term-ansicolor 1.11.3 (#3164)
  Simplify the docs sidebar and Pro landing pages (#3119)
  ...
justin808 added a commit that referenced this pull request Apr 23, 2026
* origin/main:
  fix(specs): boot dummy specs without readline and drop redundant pnpm workspace (#3190)
  docs: add RSC migration success stories page (#1985) (#3162)
  Fix Bencher reporting permanently broken on pushes to main (#3148)
  docs: add example migrations guide (#3126)
  docs: remove defunct guavapass.com reference (#3199)
  chore: remove redundant --rsc-pro install generator flag (#3105)
  ci: warn (don't fail) on Bencher main regression (#3168)
  test: enable RSpec --profile to surface slowest package tests (#3176)
  fix(node-renderer): expose performance in VM context when supportModules (#3158)
  docs: remove stale immediate_hydration references (#3139) (#3159)
  docs: restore absolute URL for node-renderer testing example (#3179)
  Bump Rspack dependencies to v2 (^2.0.0-0) (#3084)
  chore: remove obsolete webpack <5.106.0 pin (#3175)
  Move Node Renderer entry point to renderer/ directory (#3165)
  docs: address RSC pitfalls review follow-ups (#3155) (#3156)

# Conflicts:
#	CHANGELOG.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant