Walkthrough

Adds two Rake helper methods in the shakapacker_examples namespace to read Shakapacker gem version from Gemfile.lock and pin the shakapacker entry in an example app's package.json to that exact version during example generation. Also adds CONTRIBUTING guidance and tests for the new behavior.

Changes

Sequence Diagram(s)

sequenceDiagram
  participant Dev as Developer
  participant Rake as Rake Task (shakapacker_examples)
  participant FS as File System (Gemfile.lock, package.json)
  participant NPM as npm

  Dev->>Rake: invoke example generation
  Rake->>FS: read Gemfile.lock (extract shakapacker version)
  FS-->>Rake: gem version (or nil)
  alt gem version present
    Rake->>FS: read package.json
    FS-->>Rake: package.json contents
    Rake->>Rake: update dependencies/devDependencies shakapacker => gem version
    Rake->>FS: write package.json (if changed)
  end
  Rake->>NPM: run npm install (example dir)
  NPM-->>Dev: installs complete

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Pin npm shakapacker version to match gem in example generation #2558 — Implements the same pin_shakapacker_npm_version and shakapacker_gem_version_from_lockfile changes and integrates npm-version pinning into the example generation flow.

Poem

🐰 I sniffed the lockfile, found the gem’s bright tune,

I nudged package.json beneath the silvery moon,
Now bundler and npm dance in step and time,
Examples build tidy, versions aligned in rhyme.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

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

Greptile Summary

This PR adds a pin_shakapacker_npm_version helper to the example generation rake task that reads the exact shakapacker gem version from Gemfile.lock and rewrites the package.json dependencies entry to match it exactly, preventing npm's caret-range resolution from installing a newer minor version before npm install runs. The fix is well-targeted and addresses a real CI flakiness root cause.

Key observations:

• The fix is only applied in the else (latest-React) branch; the pinned_react_version? branch runs npm install --legacy-peer-deps --install-links without first calling pin_shakapacker_npm_version, leaving those examples exposed to the same mismatch if shakapacker 8.x receives a new minor release.
• The lockfile regex (\d+\.\d+\.\d+) only matches standard three-part semver; pre-release gem versions (e.g., 9.6.0.rc1) will silently bypass pinning.
• JSON.pretty_generate is already used elsewhere in the file for package.json writes, so the formatting behaviour is consistent with the existing codebase.

Confidence Score: 3/5

• Safe to merge for the immediate CI fix, but the incomplete coverage of the pinned_react_version? branch and the fragile regex leave known gaps.
• The core logic is sound and directly fixes the reported CI failure. However, the pinned_react_version? branch receives no pinning call, meaning the same bug can resurface for those examples if shakapacker 8.x is updated. The pre-release regex gap is lower risk but could silently regress. Neither issue blocks the described fix, but they reduce confidence in completeness.
• react_on_rails/rakelib/shakapacker_examples.rake — lines 148 (missing pin call in pinned_react_version? branch) and 43 (regex pattern).

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[shakapacker:install\nadds '^X.Y.Z' to package.json] --> B{example_type.pinned_react_version?}

    B -- yes --> C[apply_react_version\nwrites package.json\nReact deps only]
    C --> D[bundle_install_in]
    D --> E["npm install\n--legacy-peer-deps --install-links\n⚠️ shakapacker still '^X.Y.Z'"]
    E --> F[shakapacker:binstubs\n⚠️ gem/npm mismatch risk]

    B -- no --> G[pin_shakapacker_npm_version\nread Gemfile.lock version\nwrite exact version to package.json]
    G --> H{Gemfile.lock match\nX.Y.Z regex?}
    H -- matched --> I[overwrite package.json\nshakapacker = exact version]
    H -- no match\npre-release / missing --> J[silently skips pinning\n⚠️ mismatch risk]
    I --> K["npm install --install-links\nnpm resolves exact version ✅"]
    J --> K

_{Last reviewed commit: 39fbbb6}

The approach is sound - reading the gem version from Gemfile.lock and pinning the npm entry before npm install is the right way to prevent semver range resolution from causing version drift.

Inconsistent error handling: pin_shakapacker_npm_version parses package.json without a rescue JSON::ParserError block, while update_package_json_for_react_version catches and re-raises that error. Both follow the same read-parse-write pattern - matching the existing style would be cleaner.

Detached hash when dependencies is absent: deps = package_json["dependencies"] || {} — if the key is nil, deps is a fresh {} not stored back into package_json, so any mutation would be silently lost. In practice safe because the guard exits early when deps["shakapacker"] is nil, but the code reads as if mutating deps always propagates.

pinned_react_version? branch not covered: The fix is applied only in the else branch. The pinned_react_version? path runs npm install after apply_react_version without pinning the shakapacker npm version. Likely intentional (gem version already constrained differently for older React), but a brief comment explaining the omission would prevent future confusion.

Overall: Small, focused, correct. The Gemfile.lock regex is right and the exact-version pin strategy is the right call.

Code review notes (see inline comments for specifics): (1) Regex in shakapacker_gem_version_from_lockfile only matches X.Y.Z - pre-release versions like 9.6.0.rc1 would return nil, silently skipping the pin. (2) pin_shakapacker_npm_version is missing rescue JSON::ParserError unlike update_package_json_for_react_version. (3) The pinned_react_version? branch runs npm install without calling pin_shakapacker_npm_version - if intentionally excluded, document why. Minor: JSON.pretty_generate reformats all keys in package.json; CONTRIBUTING.md section should note react-pinned examples are not covered by this helper.

Review: Pin npm shakapacker version to match gem in example generation

The approach is sound and directly addresses the version drift problem. A couple of things worth noting:

Regex fragility in shakapacker_gem_version_from_lockfile

The pattern uses [^)]+ to capture anything inside parens after shakapacker. In a Gemfile.lock the DEPENDENCIES section contains lines like shakapacker (~> 9.0), and the GEM/specs section contains shakapacker (9.5.0). Since String#match returns the first match and specs precede DEPENDENCIES in Bundler output, this works in practice — but it relies on section ordering. A tighter pattern requiring the version to start with a digit would be safer: /^\s{4,}shakapacker \((\d[^)]*)\)/

JSON.pretty_generate silently reformats the whole file

When changed is true, the entire package.json is rewritten with JSON.pretty_generate 2-space indentation. If the generated file used different spacing the format changes beyond the version pin. Harmless for ephemeral gen-examples/ apps, but worth knowing when debugging.

Minor: rubocop disable

The Metrics/CyclomaticComplexity disable on pin_shakapacker_npm_version is understandable, but extracting a small pin_section helper would lower complexity naturally and remove the need for it.

Overall

The fix is correct and well-placed — version is pinned after bundle install (Gemfile.lock has the resolved gem version) and before any npm install call. The CONTRIBUTING.md section is a welcome addition. The regex robustness issue is the only change worth considering before merging.

Code Review

The approach here is sound - pinning the npm shakapacker version to the installed gem version after shakapacker:install is the right fix for the CI drift issue.

Potential Bug 1: Pre-release version format mismatch
Ruby gem pre-release versions use dots (e.g. 9.6.0.beta.0) but npm pre-release versions use hyphens (e.g. 9.6.0-beta.0). The spec tests that shakapacker_gem_version_from_lockfile correctly reads 9.6.0.beta.0, but pinning the npm version to that string would likely fail — npm would not recognize 9.6.0.beta.0 as a valid semver. If pre-release gem versions are ever used in CI, this would silently write an invalid version string to package.json.

Potential Bug 2: Regex fragility — could match DEPENDENCIES section
The regex \s+shakapacker\s+\(([^)]+)\) would also match the DEPENDENCIES section of Gemfile.lock if it contains a constraint like shakapacker (>= 6.0). Since String#match returns the first match and GEM specs normally appear before DEPENDENCIES, this works in practice — but it is fragile. A regex anchored to look only inside the GEM specs block would be more robust.

Missing test: non-pinned React (else) branch
The spec verifies ordering for the pinned_react_version? branch but not for the else branch. Adding a parallel test that pin_shakapacker_npm_version is called before npm install --install-links would close the coverage gap.

Minor nits

• The four-line comment explaining the pinning rationale is duplicated identically in both if/else branches. Since the method name is self-documenting, a one-line comment per branch would be cleaner.
• rubocop:disable Metrics/CyclomaticComplexity on pin_shakapacker_npm_version is slightly defensive for a method of that size.