This require "json" is unused — the implementation uses regex instead of JSON parsing. Remove it.

Defining update_gemfiles, update_package_jsons, and relative_path at the top level (outside the namespace) makes them private instance methods on Object, polluting the global method namespace for the entire Ruby process.

The pattern used by every other rake file in this repo is to call methods from ReactOnRails::TaskHelpers (included in the namespace block). The helper logic here should either be inlined into the task body, or the methods should be moved into TaskHelpers / a private module.

Note: the suggestion above keeps the line as-is — the real fix is to move all three method definitions inside a module or into TaskHelpers rather than at the top level.

No validation of the version format is performed. A caller could accidentally pass v9.6.1 (with a v prefix) or any other malformed string and the task would silently write it into every file.

The require "json" on this line is imported but never used. The implementation correctly relies on regex substitution to avoid JSON reformatting artifacts, so this dependency can be safely removed.

Unused require "json" import in rake file

Low Severity

require "json" is imported but never used anywhere in the file. The implementation deliberately uses regex-based replacement (as noted in comments) instead of JSON parsing to preserve formatting. The JSON module is never referenced. This appears to be a leftover from an earlier implementation approach that was switched to regex.

Regenerate pnpm lockfile after shakapacker bump

This version bump updates workspace package.json files to 9.6.1 but does not update pnpm-lock.yaml (which still pins these importers to 9.6.0), so CI jobs that run pnpm install --frozen-lockfile (for example in .github/workflows/lint-js-and-ruby.yml and other frozen-lockfile workflows) will fail before tests run.

Useful? React with 👍 / 👎.

Update Gemfile.lock when changing shakapacker Gemfile pin

The Gemfile pin is changed to 9.6.1 while the corresponding lockfiles still resolve shakapacker (9.6.0), and Ruby CI runs with BUNDLE_FROZEN=true for the latest matrix (see .github/workflows/gem-tests.yml), so bundle install in react_on_rails will fail due to frozen lockfile mismatch.

Useful? React with 👍 / 👎.

asdf shell ruby #{version} sets the Ruby version in the current shell session, but when the command is executed as a subprocess via sh, it runs in a child shell that exits immediately — the environment change never takes effect for the subsequent bundle update shakapacker call in the same string.

The reliable approach for asdf is to use either asdf exec or the env var directly:

Note the same issue exists in task_helpers.rb's bundle_install_with_ruby_version.

The regex only matches double-quoted gem "shakapacker" declarations. Gemfiles that use single quotes (gem 'shakapacker', '9.6.0') will be silently skipped.

Or more simply, extend the character class to match both quote styles:

/gem ["']shakapacker["'],\s*"(=\s*)?[\d.]+(?:[a-zA-Z0-9.\-]*)"/

(Full fix would also handle single-quoted version strings, but the Gemfiles in this repo appear to use double quotes consistently, so this may be acceptable as a known limitation — worth documenting with a comment.)

This duplicates the version-manager case logic from task_helpers.rb's bundle_install_with_ruby_version, but with two differences:

1. It adds mise support (which task_helpers.rb is missing).
2. It raises immediately on an unknown manager, whereas task_helpers.rb prints a user-friendly warning before raising.

Consider extracting the shared "build the switch command for manager X" logic into a single method in TaskHelpers (e.g., ruby_version_switch_command(version, cmd)) that both bundle_install_with_ruby_version and bundle_update_with_ruby_version can call. This would also let you add mise support to bundle_install_in in one place.

The rescue here is attached to the do..end block (implicit begin), which is valid Ruby but can be surprising: it catches errors from all code in the block, including File.dirname and shakapacker_relative_path, not just bundle_update_shakapacker_in.

Also note that if bundle_update_shakapacker_in raises, rel will have already been set, so the rescue message is correct — but it's still worth an explicit begin/rescue/end around just the call you intend to be fallible:

gemfile_locks.each do |lockfile|
  dir = File.dirname(lockfile)
  rel = shakapacker_relative_path(dir)
  puts "  bundle update shakapacker in #{rel}"
  begin
    bundle_update_shakapacker_in(dir)
  rescue StandardError => e
    puts "    WARNING: Failed to update #{rel}: #{e.message}"
    puts "    You may need to update this lock file manually."
  end
end

Minor: the outer capture group with ? is redundant since * already allows zero matches. This is harmless but slightly confusing:

/\A\d+\.\d+\.\d+[.\-a-zA-Z0-9]*\z/

Also, the . inside the character class is a literal dot (which is correct), but - should be placed first or last to avoid being interpreted as a range in some contexts — though \- works fine here.

⚠️ Potential issue | 🟡 Minor

Tighten the version validator.

/\A\d+\.\d+\.\d+([.\-a-zA-Z0-9]*)?\z/ also accepts malformed inputs like 9.6.1- and 9.6.1...., so a typo can rewrite multiple manifests before anything fails.

-    unless version.match?(/\A\d+\.\d+\.\d+([.\-a-zA-Z0-9]*)?\z/)
+    unless version.match?(/\A\d+\.\d+\.\d+(?:[-.][0-9A-Za-z]+)*\z/)
       raise "Invalid version format '#{version}'. Expected semver like '9.6.1' or '9.6.0.beta.0'"
     end

Verify each finding against the current code and only fix it if needed.

In `@react_on_rails/rakelib/shakapacker_version.rake` around lines 13 - 14, The
version validation regex in the unless block (the version.match? check) is too
permissive and allows trailing or repeated separators like "9.6.1-" or
"9.6.1...."; replace the existing pattern with a stricter one that requires an
initial MAJOR.MINOR.PATCH and only allows additional prerelease/build segments
that begin with a dot or dash followed by at least one alphanumeric token (no
empty tokens, no trailing separators). Update the regex used in the unless
condition (the version.match? call) to enforce the pattern so only valid
semver-like strings such as "9.6.1", "9.6.0.beta.0", or "9.6.1-rc1" pass.

⚠️ Potential issue | 🟠 Major

#!/bin/bash
python - <<'PY'
from pathlib import Path

for lockfile in sorted(Path('.').rglob('Gemfile*.lock')):
    if lockfile.name == 'Gemfile.lock':
        continue
    if any(part in {'.git', 'node_modules'} for part in lockfile.parts):
        continue

    text = lockfile.read_text(errors='ignore')
    if 'shakapacker' not in text:
        continue

    gemfile = lockfile.with_suffix('')  # strip .lock
    print(f"missed lockfile: {lockfile}")
    print(f"  matching gemfile: {gemfile} (exists={gemfile.exists()})")
PY

fd -e development_dependencies

find . -name "*development_dependencies*" -type f | grep -v ".git" | head -20

find . -name "Gemfile.development_dependencies.lock" -type f | grep -v ".git"

grep -r "shakapacker" react_on_rails/Gemfile.development_dependencies react_on_rails_pro/Gemfile.development_dependencies 2>/dev/null || echo "shakapacker not found"

cat react_on_rails/Gemfile.development_dependencies react_on_rails_pro/Gemfile.development_dependencies

cat -n react_on_rails/rakelib/shakapacker_version.rake

grep -n "bundle_update_shakapacker_in" react_on_rails/rakelib/shakapacker_version.rake

cat -n react_on_rails/rakelib/task_helpers.rb

grep -A5 "unbundled_sh_in_dir\|sh_in_dir" react_on_rails/rakelib/task_helpers.rb | head -30

Handle non-default lockfiles to maintain consistency with updated Gemfiles.

This task updates all Gemfile* variants including Gemfile.development_dependencies (lines 26–48), but only bundles Gemfile.lock files (line 74). If Gemfile.development_dependencies is bundled elsewhere, its lockfile will not be regenerated here, leaving dependencies inconsistent. The bundle_update_shakapacker_in helper needs to accept the originating Gemfile basename (e.g., Gemfile.development_dependencies) and pass it via BUNDLE_GEMFILE environment variable so Bundler processes the correct manifest.

Verify each finding against the current code and only fix it if needed.

In `@react_on_rails/rakelib/shakapacker_version.rake` around lines 74 - 82, The
task iterates over Gemfile* variants but only targets Gemfile.lock files; update
the loop and the bundle_update_shakapacker_in helper so it accepts the
originating Gemfile basename (e.g., "Gemfile.development_dependencies") and uses
that to set BUNDLE_GEMFILE when invoking Bundler; specifically, when iterating
in the block that computes rel via shakapacker_relative_path and calls
bundle_update_shakapacker_in(dir), also determine the matching Gemfile basename
for that lockfile and pass it into bundle_update_shakapacker_in(dir,
gemfile_basename), and modify bundle_update_shakapacker_in to export
ENV["BUNDLE_GEMFILE"]=gemfile_basename (or the full path) before running bundle
update so Bundler regenerates the correct lockfile for non-default manifests.

private has no effect here. Inside a Rake namespace block, def methods are defined on main (the top-level object), not inside a class or module body, so the private call does not restrict visibility. The methods remain publicly accessible globally. The existing shakapacker_examples.rake omits this marker entirely, which is the correct approach — the private call should be removed to avoid creating a false impression of encapsulation.

This regex only matches double-quoted gem declarations. Single-quoted entries like gem 'shakapacker', '9.6.0' would be silently skipped, leaving that file stale with no warning. Consider expanding the pattern to handle both quote styles:

Or more robustly, use a character class for the surrounding quotes:

/gem (["'])shakapacker\1,\s*(["'])(=\s*)?[\d.]+(?:[a-zA-Z0-9.\-]*)\2/

This method duplicates nearly all of bundle_install_with_ruby_version in task_helpers.rb, differing only in the bundler subcommand. It also introduces a silent inconsistency: this version supports mise but the original in task_helpers.rb does not, so users relying on mise will find that bundle_install_in fails while bundle_update_shakapacker_in succeeds.

Consider extracting a shared helper into task_helpers.rb that accepts the command:

def run_bundler_with_ruby_version(dir, version, bundler_cmd)
  version_manager = ENV.fetch("RUBY_VERSION_MANAGER", "rvm")
  cmd = case version_manager
        when "rvm"   then "rvm #{version} do #{bundler_cmd}"
        when "rbenv" then "RBENV_VERSION=#{version} #{bundler_cmd}"
        when "asdf"  then "asdf shell ruby #{version} && #{bundler_cmd}"
        when "mise"  then "mise exec ruby@#{version} -- #{bundler_cmd}"
        else raise "Unsupported RUBY_VERSION_MANAGER: #{version_manager}"
        end
  unbundled_sh_in_dir(dir, cmd)
end

Then both callers become one-liners, and mise support is available everywhere.

⚠️ Potential issue | 🟡 Minor

Narrow the documented scope of lockfile updates.

react_on_rails/rakelib/shakapacker_version.rake:71-92 does not update all Gemfile.lock files: it skips gen-examples and only touches lockfiles that already contain shakapacker. Reword this to "all relevant shakapacker references and associated lockfiles" so the docs match the task behavior.

-Use `rake shakapacker:update_version[VERSION]` to update shakapacker across the entire monorepo. This single command updates all Gemfiles, package.json files, Gemfile.lock files, and pnpm-lock.yaml. Do **not** manually edit individual version references — always use the rake task to keep everything in sync.
+Use `rake shakapacker:update_version[VERSION]` to update shakapacker across the entire monorepo. This single command updates shakapacker version references in Gemfiles and package.json files, refreshes the relevant Gemfile.lock files, and regenerates `pnpm-lock.yaml`. Do **not** manually edit individual version references — always use the rake task to keep everything in sync.

Verify each finding against the current code and only fix it if needed.

In `@AGENTS.md` around lines 65 - 67, The documentation overstates the rake task's
scope; update the phrasing around the shakapacker:update_version rake task
(referenced in react_on_rails/rakelib/shakapacker_version.rake and the task name
shakapacker:update_version) to reflect that it updates "all relevant shakapacker
references and associated lockfiles" rather than every Gemfile.lock — note that
it skips gen-examples and only modifies lockfiles that already contain
shakapacker; adjust the AGENTS.md text to use that narrower wording and keep the
rest of the usage/flags guidance unchanged.

This regex only matches double-quoted gem declarations. Gemfiles using single quotes (gem 'shakapacker', '9.6.0') will be silently skipped. Consider broadening the pattern to match either quote style:

Or, simpler to capture and replace correctly, use a capture group approach that handles both quote styles.

This method duplicates bundle_install_with_ruby_version from task_helpers.rb with one meaningful difference: it adds mise support that task_helpers.rb lacks. This divergence means mise users get inconsistent behavior — it works here but not with bundle_install_in.

Consider refactoring task_helpers.rb to accept the bundle subcommand as a parameter and reuse it here, e.g.:

def bundle_run_with_ruby_version(dir, version, subcommand)
  version_manager = ENV.fetch("RUBY_VERSION_MANAGER", "rvm")
  cmd = case version_manager
        when "rvm"   then "rvm #{version} do bundle #{subcommand}"
        when "rbenv" then "RBENV_VERSION=#{version} bundle #{subcommand}"
        when "asdf"  then "asdf shell ruby #{version} && bundle #{subcommand}"
        when "mise"  then "mise exec ruby@#{version} -- bundle #{subcommand}"
        else raise "Unsupported RUBY_VERSION_MANAGER: #{version_manager}"
        end
  unbundled_sh_in_dir(dir, cmd)
end

This way both bundle install and bundle update shakapacker use the same logic, including mise.

Pathname is used here without an explicit require 'pathname'. This works in most Rails/Rake contexts because it's loaded transitively, but it's fragile. Add require 'pathname' at the top of the file alongside require_relative "task_helpers".

Hardcoding 9.6.1 here will make this example stale after the next version bump. Prefer a placeholder:

⚠️ Potential issue | 🟡 Minor

Document this task with bundle exec rake.

Line 60 and Line 65 currently show a plain rake invocation even though this repo’s policy is to run Ruby commands through Bundler. Please document the new task as bundle exec rake shakapacker:update_version[...] so agents don’t run it against the wrong gem set.

-# Dependency version updates
-rake shakapacker:update_version[9.6.1]  # Update shakapacker across the monorepo
+# Dependency version updates
+bundle exec rake shakapacker:update_version[9.6.1]  # Update shakapacker across the monorepo

-Use `rake shakapacker:update_version[VERSION]` to update shakapacker across the entire monorepo.
+Use `bundle exec rake shakapacker:update_version[VERSION]` to update shakapacker across the entire monorepo.

Based on learnings: Use bundle exec for Ruby commands.

Verify each finding against the current code and only fix it if needed.

In `@AGENTS.md` around lines 59 - 65, Update the documented rake invocation to run
under Bundler: replace occurrences of "rake shakapacker:update_version[...]"
(including the example "rake shakapacker:update_version[9.6.1]") with "bundle
exec rake shakapacker:update_version[VERSION]" (or "bundle exec rake
shakapacker:update_version[9.6.1]" for the example) so the task is always run
via Bundler.