chore: remove redundant --rsc-pro install generator flag#3105
chore: remove redundant --rsc-pro install generator flag#3105
Conversation
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughRemoved the Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Review: chore: remove redundant --rsc-pro install generator flagThe intent is clear and the mechanics are correct — collapsing Behavioral gap:
|
Greptile SummaryThis PR removes the Confidence Score: 5/5Safe 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
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"]
Reviews (1): Last reviewed commit: "chore: remove --rsc-pro install generato..." | Re-trigger Greptile |
There was a problem hiding this comment.
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 | 🟡 MinorSuccessful prerelease
--rscinstalls 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--proprerelease 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
📒 Files selected for processing (6)
CHANGELOG.mdreact_on_rails/lib/generators/react_on_rails/generator_helper.rbreact_on_rails/lib/generators/react_on_rails/install_generator.rbreact_on_rails/lib/generators/react_on_rails/pro_setup.rbreact_on_rails/spec/react_on_rails/generators/generator_helper_spec.rbreact_on_rails/spec/react_on_rails/generators/install_generator_spec.rb
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>
b878fc7 to
0d4481f
Compare
Code ReviewOverall: 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 Issues1. Stale method name (inline comment posted): 2. Silent exact-pinning for 3. Missing test for Observations / non-blocking
|
There was a problem hiding this comment.
💡 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".
There was a problem hiding this comment.
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 | 🟡 MinorAdd
--proprerelease coverage or stabilize the existing--prospec.Line 540 now exact-pins prereleases for all Pro installs, not only
--rsc. The nearby--promissing-gem spec still depends on the repository’s currentReactOnRails::VERSIONand expects a~>requirement, so it can fail during a prerelease cycle unless that example stubs a stable version or a separate--proprerelease 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
📒 Files selected for processing (6)
CHANGELOG.mdreact_on_rails/lib/generators/react_on_rails/generator_helper.rbreact_on_rails/lib/generators/react_on_rails/install_generator.rbreact_on_rails/lib/generators/react_on_rails/pro_setup.rbreact_on_rails/spec/react_on_rails/generators/generator_helper_spec.rbreact_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>
Code Review: Remove redundant
|
- 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>
Address-review summaryScan scope: full PR history (no prior summary comment). Mattered
Optional
Skipped
Next default scan starts after this comment. Say |
Code ReviewOverviewClean, well-motivated removal of the redundant Issues1. New behavior for
2. Removed The deleted context verified exact npm version strings for 3. Breaking change: no in-code migration path for After this PR, passing Nits
SummaryThe simplification is sound and well-scoped. Main asks before merging: (1) add a prerelease test for |
- 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>
|
Thanks @claude, addressing each point: Issue 1 ( Issue 2 (npm version-pin assertions): addressed in f7c161a. Strengthened the Issue 3 (friendly migration message for Nits:
|
Address-review summaryScan scope: review activity after 2026-04-21T18:20:41Z (previous summary). Mattered
Optional
Skipped
Next default scan starts after this comment. Say |
|
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:
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>
|
Thanks @claude for the re-review. Addressing each point:
|
Address-review summaryScan scope: review activity after 2026-04-21T18:45:29Z (previous summary). Mattered
Optional
Skipped
Next default scan starts after this comment. Say |
Code ReviewOverall: Clean, well-motivated removal. The PR correctly identifies that What works well
IssuesUndocumented behavioral expansion in
|
|
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 Missing stable-version pinning test — skipping. Tests the opposite branch of
|
Address-review summaryScan scope: review activity after 2026-04-21T18:59:05Z (previous summary). Mattered
Optional
Skipped
Next default scan starts after this comment. Say |
…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
…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) ...
* 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
Summary
#2821 introduced a dedicated
--rsc-proinstall flag. It was closed the nextday 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
gem version
Gem::Version.new(ReactOnRails::VERSION).prerelease?instead of the flag —this is the real reason exact pinning matters (Bundler's
~>doesn't matchprereleases), not a flag-specific behavior
Side effect: plain
--rscon a prerelease gem version now installs correctlywhere it previously would have failed against
~>pinning.What is removed
class_option :rsc_prouse_rsc_pro_mode?helper--rsc-probranches inuse_pro?,use_rsc?,pro_requirement_flag,recovery_install_command--rsc-protest contextsWhat is NOT touched
pro_generator.rbandpro_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 rubocopon all modified files — clean🤖 Generated with Claude Code
Summary by CodeRabbit
Removed
--rsc-prohas been removed.Changed
--rsc-pronow apply when using--rsc(post-install verification checklist, prerelease install notes, and exact Pro gem pinning for prereleases).Chore