Update Shakapacker to 10.2.0

[justin808]

Summary

• Updates Shakapacker gem/npm dependencies to 10.2.0.
• Keeps css-loader on the Shakapacker 10.2-compatible v6 line (^6.8.1, resolved to 6.11.0) instead of taking the v7 major bump.
• Minimizes the Ruby lockfile refresh: Gemfile.lock now changes only shakapacker 10.1.0 -> 10.2.0 and the required transitive rack-proxy 0.8.2 -> 0.8.3; the unrelated crass/i18n/json/nokogiri/pp/rdoc/rbs drift from the earlier PR head was removed in 8573a1b44bc282f73b011bebea7cb726d821c08a.
• Keeps the Rspack dependency family on the Shakapacker 10.2 peer-compatible line: @rspack/cli/@rspack/core 2.0.4 and @rspack/plugin-react-refresh 2.0.0 satisfy Shakapacker 10.2.0's ^2.0.0 peer ranges.

Dependency Notes

• Bundler refresh was regenerated from the base lockfile with only shakapacker unlocked, so the Ruby diff is scoped to Shakapacker plus rack-proxy.
• css-loader stays on 6.11.0 to avoid the unrelated v7 CSS Modules semantic change while satisfying Shakapacker's ^6.8.1 || ^7.0.0 peer range.
• This app currently has assets_bundler: webpack; bin/shakapacker-dev-server therefore exercises the webpack HMR path. The Rspack React Refresh plugin was also smoke-tested directly with @rspack/core@2.0.4 to confirm the 2.0 plugin exports a constructible plugin with apply().

Verification

• bin/conductor-exec bundle check
• bin/conductor-exec yarn install --frozen-lockfile
• git diff --check
• git diff --check origin/master...HEAD
• bin/conductor-exec bundle exec rubocop
• bin/conductor-exec yarn test:client
• bin/conductor-exec yarn build:test
• Rspack compatibility probe: @rspack/core 2.0.4 + @rspack/plugin-react-refresh 2.0.0 constructs ReactRefreshRspackPlugin and exposes apply().
• Node renderer/focused RSpec: started NODE_ENV=test bin/conductor-exec node renderer/node-renderer.js, then ran RAILS_ENV=test NODE_ENV=test bin/conductor-exec bin/rspec spec/requests/server_render_check_spec.rb spec/system/destroy_comment_spec.rb (3 examples, 0 failures).
• Dev-server/HMR smoke: RAILS_ENV=development NODE_ENV=development bin/conductor-exec bin/shakapacker-dev-server loaded development config, served on localhost:3035, and compiled the client/HMR bundle successfully.

AI disclosure: Prepared by OpenAI Codex from the prompt: "Post PRs to update react_on_rails and all major example, starter repos to shakapacker 10.2.0."

Summary by CodeRabbit

• Chores
  • Updated frontend build and tooling packages to newer versions for improved compatibility and stability, including Rspack-related integrations and CSS loader updates.
• Tests
  • Strengthened system test coverage to verify that a success notice is shown after creating a comment via the standard page flow.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 08b2902a-8fe6-43aa-9c78-24375c8b8401

📥 Commits

Reviewing files that changed from the base of the PR and between 8573a1b and 937d7b5.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (1)

• package.json

🚧 Files skipped from review as they are similar to previous changes (1)

• package.json

---

Walkthrough

This PR bumps shakapacker and Rspack-related dependency versions in Gemfile and package.json, and adds a notice-message assertion to a system spec for comment creation.

Changes

Dependency version bumps and test update

Layer / File(s)	Summary
Shakapacker and Rspack dependency upgrades Gemfile, package.json	Bumps shakapacker to 10.2.0, @rspack/cli and @rspack/core to 2.0.4, css-loader to ^6.8.1, @rspack/dev-server to ^2.0.4, @rspack/plugin-react-refresh to 2.0.0, and rspack-manifest-plugin to ^5.2.2.
Comment creation notice assertion spec/system/destroy_comment_spec.rb	Adds an expectation that the #notice element shows "Comment was successfully created." after submitting the new comment form.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related issues

• Follow-up: Exercise Rspack 2 switcher path in tutorial #774: Updates the same Shakapacker/Rspack dependency set.
• Rspack React Refresh v2 named export breaks existing dev configs during Shakapacker 10.2 upgrade shakapacker#1204: Matches the Shakapacker 10.2 and @rspack/plugin-react-refresh v2 upgrade path.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the primary change: upgrading Shakapacker to 10.2.0.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jg-codex/chore/update-shakapacker-10-2-0

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🚀 Quick Review App Commands

Welcome! Here are the commands you can use in this PR:
They require the repository to have cpflow review apps configured, including the CPLN_TOKEN_STAGING secret.

+review-app-deploy

Deploy your PR branch for testing.

+review-app-delete

Remove the review app when done.

+review-app-help

Show detailed instructions, environment setup, and configuration options.

Comment +review-app-help for full setup details.

[claude]

Review: Update Shakapacker to 10.2.0

Overall this is a clean, mechanical dependency bump (Gemfile/Gemfile.lock/package.json/yarn.lock) with no application code changes. A few observations:

Worth double-checking before merge (left an inline comment with detail):

• css-loader moves from ^6.7.3 to ^7.1.4 — a major version bump pulled in transitively by Shakapacker 10.2.0. This repo has custom logic in config/webpack/commonWebpackConfig.js and config/webpack/serverWebpackConfig.js that manipulates css-loader's modules options (namedExport, exportLocalsConvention, exportOnlyLocals for the SSR-only-locals bundle). Since css-loader v7 changed some modules-related option semantics, it's worth confirming CSS Modules and the SSR-only-locals bundle still work correctly rather than relying solely on bundle check / yarn install --frozen-lockfile (neither exercises the webpack/rspack build). The rspec_test CI job does build both bundles, so a green run there is good evidence, but it's worth a quick look to make sure it isn't silently emitting extra CSS text into the server bundle.
• @rspack/plugin-react-refresh also jumps a major version (1.6.1 → 2.0.0), alongside @rspack/cli/@rspack/core going from a 2.0.0-beta.7 prerelease to the stable 2.0.4. These look like expected/required companions to the Shakapacker bump, but same caveat: worth confirming HMR/react-refresh still works in dev (bin/dev), since prerelease → stable jumps sometimes change plugin option shapes.

Lower risk / FYI:

• Gemfile.lock also picks up unrelated gem bumps (nokogiri, i18n, json, crass, pp, and a rdoc 7→8 major bump that adds a new rbs dependency). These look like the natural result of a bundle update re-resolving the graph rather than anything scoped to Shakapacker — rdoc/rbs are dev-only (doc generation) so no runtime risk, but flagging since the PR title/description imply a Shakapacker-only change.

Security: No new/unfamiliar package sources — all resolved from the standard npmjs/rubygems registries with matching integrity hashes. Nothing that looks like a supply-chain concern.

No functional code changes to review otherwise; this is safe to merge once CI (in particular the test job that builds bundles) is green.

[claude]

Reviewed this dependency-bump PR (Shakapacker 10.1.0 → 10.2.0 + lockfile refresh). Summary:

Findings: none blocking. This is a clean, mechanical update:

• Gemfile/Gemfile.lock: shakapacker bumped consistently in both the GEM and DEPENDENCIES sections. Transitive gem bumps (crass, i18n, json, nokogiri x3 platforms, pp, rack-proxy, rdoc 7→8 w/ new rbs dep) are all patch/minor-level and dev/runtime-appropriate — nothing pulls in unpinned or non-registry sources.
• package.json/yarn.lock: @rspack/* bumped from 2.0.0-beta.7 to the stable 2.0.4, rspack-manifest-plugin and @rspack/plugin-react-refresh bumped accordingly. css-loader intentionally kept on the v6 line (^6.8.1) rather than jumping to v7, which avoids an unrelated breaking change — good call, and it's called out explicitly in the PR description along with static verification that CSS Modules output is unaffected.
• No suspicious/non-registry.npmjs.org resolved URLs anywhere in the yarn.lock diff.
• spec/system/destroy_comment_spec.rb: adds expect(page).to have_css("#notice", text: "Comment was successfully created.") before clicking "Back" — this matches the existing pattern in spec/system/edit_comment_spec.rb and looks like a reasonable flakiness fix (waiting for the create-comment round trip to finish before navigating away) rather than something masking a real bug.

No security, performance, or correctness concerns found. Nice that verification steps (bundle check, frozen yarn install, build:test, system spec run with node-renderer) are documented in the PR description.

[claude]

Review summary

Overall this is a low-risk, mechanical dependency-bump PR and looks solid. A few notes:

Good:

• css-loader is correctly held on the v6 line (^6.8.1, resolving to 6.11.0) to stay compatible with Shakapacker 10.2 rather than jumping to the v7 major — sensible and explicitly verified per the description.
• The added assertion in spec/system/destroy_comment_spec.rb (waiting for the #notice flash before clicking "Back") is a legitimate stabilization fix — the app does render <p id="notice"> in app/views/comments/index.html.erb and show.html.erb, so this should reduce flakiness rather than mask a real issue.
• No application config (config/webpack/*.js, config/shakapacker.yml) needed changes for this bump, consistent with a patch-level Shakapacker update.

Worth a second look (left as inline comments):

1. Gemfile.lock picked up several transitive gem bumps unrelated to Shakapacker (crass, i18n, json, nokogiri, pp, rack-proxy), plus a major rdoc 7→8 bump that adds a new rbs dependency. Likely harmless (lockfile re-resolution side effect, all dev/doc gems), but not mentioned in the PR description.
2. package.json bumps @rspack/plugin-react-refresh a full major version (1.6.1 → 2.0.0) alongside the @rspack/cli/@rspack/core beta→stable jump. This plugin is auto-registered by Shakapacker only in dev-server mode, so it wouldn't be exercised by the production-mode yarn build:test verification mentioned in the description — worth confirming HMR/Fast Refresh still works via bin/dev before merging.

No security concerns identified; changes are limited to dependency manifests/lockfiles and one test assertion.

[justin808]

Address-review summary

Scan scope: full PR history for PR #771 on head 8573a1b44bc282f73b011bebea7cb726d821c08a.

Mattered

• Addressed Gemfile.lock drift: regenerated the lockfile so only shakapacker and rack-proxy change; unrelated rdoc/rbs and other transitive drift was removed.
• Addressed Rspack compatibility proof: documented Shakapacker 10.2 peer ranges, direct Rspack React Refresh plugin constructor smoke, and dev-server/HMR smoke evidence.

Skipped

• None.

Deferred-work tracking: none.

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

[claude]

Review

This PR bumps Shakapacker to 10.2.0 (Gemfile/Gemfile.lock + package.json/yarn.lock), pulls in the matching transitive updates (@rspack/cli/@rspack/core 2.0.0-beta.7 → 2.0.4, @rspack/plugin-react-refresh 1.6.1 → 2.0.0, rspack-manifest-plugin → 5.2.2, rack-proxy → 0.8.3), deliberately keeps css-loader pinned to the v6 line, and adds one assertion to spec/system/destroy_comment_spec.rb.

Findings: none survived verification — this is a clean, low-risk dependency bump.

Checks performed:

• Version references for shakapacker are consistent across Gemfile, Gemfile.lock, and package.json (all 10.2.0) — no partial-bump drift.
• css-loader stays on ^6.8.1 (resolves to 6.11.0) as stated in the PR description, avoiding the v7 major.
• No patches/ entries target any of the bumped packages, so nothing here silently breaks a patched dependency.
• Node engine requirement (>=22) is satisfied by .nvmrc (22.12.0) and CI workflow config.
• The added line in destroy_comment_spec.rb:

  expect(page).to have_css("#notice", text: "Comment was successfully created.")

  matches actual app behavior exactly — CommentsController#create sets notice: I18n.t(:comment_was_successfully_created) (config/locales/en.yml:24 → "Comment was successfully created."), and comments/show.html.erb renders it as <p id="notice">. The "classic page" context in this spec isn't a Turbo Frame request, so this branch is guaranteed to execute, and Capybara's have_css auto-waits — no flakiness risk. This looks like a good stabilization addition (guards against racing the redirect before clicking "Back").

Nothing else in the diff (Gemfile.lock/yarn.lock churn) shows inconsistency or leftover stale version pins.

[greptile-apps]

Greptile Summary

This PR updates the app to Shakapacker 10.2.0. The main changes are:

• Ruby Shakapacker and rack-proxy lockfile updates.
• npm Shakapacker, Rspack, React Refresh, manifest plugin, and css-loader range updates.
• A system spec wait for the comment creation notice before destroying the comment.

Confidence Score: 5/5

This looks safe to merge after checking the CSS module config path.

• No blocking issues found in the changed code.
• The only follow-up is a compatibility check around Shakapacker-generated css-loader rules and the local CSS Modules patch.

package.json

Important Files Changed

Filename	Overview
Gemfile	Pins the Ruby Shakapacker gem to 10.2.0.
Gemfile.lock	Refreshes the Ruby lockfile for Shakapacker 10.2.0 and rack-proxy 0.8.3.
package.json	Updates Shakapacker and related JavaScript bundler dependencies, with one CSS Modules compatibility path worth checking.
yarn.lock	Refreshes resolved JavaScript dependencies for the new Shakapacker and Rspack versions.
spec/system/destroy_comment_spec.rb	Adds a Capybara wait for the successful creation notice before continuing the destroy flow.

_{Reviews (1): Last reviewed commit: "Minimize Shakapacker lockfile refresh" | Re-trigger Greptile}

[claude]

Review Summary

This is a well-scoped, well-documented dependency bump PR. Reviewed for code quality, bugs, security, and performance.

What it does:

• shakapacker 10.1.0 → 10.2.0 (Gemfile/Gemfile.lock), with the Ruby lockfile diff correctly minimized to just shakapacker + the required rack-proxy 0.8.2 → 0.8.3 bump.
• css-loader deliberately held on the 6.x line (^6.8.1, resolves to 6.11.0) to stay within Shakapacker 10.2's ^6.8.1 || ^7.0.0 peer range while avoiding the v7 CSS Modules semantic change — good call, and clearly explained.
• Rspack family (@rspack/cli/core 2.0.4, @rspack/plugin-react-refresh 2.0.0, rspack-manifest-plugin ^5.2.2) bumped to satisfy Shakapacker 10.2's peer ranges.
• A stabilization tweak to spec/system/destroy_comment_spec.rb: adds expect(page).to have_css("#notice", text: "Comment was successfully created.") before navigating away. Verified this selector/text matches the actual view (app/views/comments/show.html.erb) and the I18n.t(:comment_was_successfully_created) string in config/locales/en.yml — this is a correct fix for a race where the "Back" link could be clicked before the create had fully rendered.

Security: No concerning changes — rack-proxy bump is a patch version, and the rest is toolchain/build dependencies with no runtime security surface for this app.

Correctness/risk: Left one inline note — the rspack packages take a beta→stable jump plus a major version bump on the react-refresh plugin, but this app currently runs assets_bundler: webpack (per config/shakapacker.yml), so none of that is exercised by CI/the test suite, only by a manual smoke check described in the PR body. Given the repo has a TODO to flip back to rspack later, it'd be worth a tracking note to properly re-verify this exact version combination when that switch happens.

Overall: low risk, changes match their stated scope, and the included test fix is legitimate and verified against the actual app code.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8573a1b44b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Review: Update Shakapacker to 10.2.0

Overall this is a clean, well-scoped dependency bump. The lockfile diffs are minimal and match what's described in the PR body, the css-loader/Rspack peer ranges look correctly satisfied, and the added system-test assertion (spec/system/destroy_comment_spec.rb) is correct — it checks the #notice element rendered in app/views/comments/show.html.erb against the exact i18n string in config/locales/en.yml.

Issue found

Stale version references in README.md (not part of this diff, so I can't leave an inline comment on it): the "Version Targets" section at README.md:191-192 still lists:

- `shakapacker` gem/npm package: `10.1.0`
- `@rspack/core` and `@rspack/cli`: `2.0.0-beta.7`

This PR bumps shakapacker to 10.2.0 and @rspack/core/@rspack/cli to 2.0.4 in Gemfile/package.json, but the README table wasn't updated to match, so it will now be misleading to anyone consulting it for the project's pinned versions.

Minor observations (non-blocking)

• @rspack/dev-server is added as a new devDependency but isn't referenced directly anywhere in config/, bin/, or client/ — presumably it's a transitive requirement pulled in by Shakapacker 10.2's Rspack dev-server integration rather than something this repo calls directly. Worth double-checking it's actually needed (vs. an incidental yarn install artifact) since it wasn't called out explicitly in the PR description's dependency notes.
• No security concerns identified in the version bumps themselves (rack-proxy 0.8.2→0.8.3, shakapacker 10.1.0→10.2.0, Rspack 2.0.0-beta.7→2.0.4, css-loader minor bump within v6).

[github-actions]

✅ Review App Deleted

Review app for PR #771 is deleted

🎮 Control Plane Console
📋 View Workflow Logs