Fix stale and broken documentation across Shakapacker guides#1023
Fix stale and broken documentation across Shakapacker guides#1023
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
WalkthroughThis PR makes documentation-only edits across many docs: command examples now favor Bundler/rake, Node and dependency guidance updated, API/config examples switched to symbol-keyed access, bundler/transpiler/React/TypeScript docs revised, and several small formatting and example fixes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Greptile SummaryThis is a docs-only sweep across 22 files that fixes stale commands, broken local links, and outdated version/API guidance accumulated since the Shakapacker v9 release. No source code is changed.\n\nKey corrections made:\n- Confidence Score: 5/5Safe to merge — docs-only change set with no source code modifications and no test-suite impact. All 22 changed files are documentation. The corrections are accurate and well-scoped. The two P2 comments are non-blocking style suggestions and do not affect correctness of the rest of the PR. docs/api-reference.md (return-type examples worth a spot-check against source), docs/transpiler-migration.md (active Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User installs Shakapacker] --> B{Choose bundler}
B -->|webpack| C[config/webpack/webpack.config.js]
B -->|rspack| D[config/rspack/rspack.config.js]
C --> E{Choose transpiler}
D --> E
E -->|swc default| F[SWC via swc-loader]
E -->|babel| G[Babel via babel-loader]
E -->|esbuild| H[esbuild via esbuild-loader]
F --> I{HMR enabled?}
G --> I
H --> I
I -->|webpack + HMR| J[react-refresh-webpack-plugin auto-added]
I -->|rspack + HMR| K[rspack plugin-react-refresh auto-added]
I -->|no HMR| L[Production build via bundle exec rake]
J --> M[bin/shakapacker-dev-server]
K --> M
Reviews (1): Last reviewed commit: "docs: fix stale and broken guides" | Re-trigger Greptile |
| // Override v9 default to use v8-style default exports | ||
| cssLoaderUse.options.modules.namedExport = false | ||
| cssLoaderUse.options.modules.exportLocalsConvention = "asIs" | ||
| cssLoaderUse.options.modules.exportLocalsConvention = "camelCase" |
There was a problem hiding this comment.
Behavioral difference between
"asIs" and "camelCase" worth noting
The change from "asIs" to "camelCase" is semantically meaningful:
"asIs"→ class names are exported exactly as written (.my-class→styles['my-class'])"camelCase"→ both the original and a camelCase form are exported (.my-class→ bothstyles['my-class']andstyles.myClass)
If the goal is to restore the css-loader v6 default (which was "camelCase"), this change is correct. However, users who previously adopted the code from this guide using "asIs" to preserve hyphenated class names verbatim will now observe different exports. Updating the inline comment to note this difference would help readers understand the change:
| cssLoaderUse.options.modules.exportLocalsConvention = "camelCase" | |
| cssLoaderUse.options.modules.exportLocalsConvention = "camelCase" // exports both original and camelCase forms; matches css-loader v6 default |
The same concern applies to the parallel occurrence in the Sass modules example.
|
test comment |
Documentation ReviewOverall this is a solid docs pass — most corrections are accurate against the actual source code. Two issues worth addressing before merge, plus one pre-existing bug worth fixing since the surrounding code is being touched. |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/cdn_setup.md`:
- Around line 208-210: Replace the weak verification step that uses "grep
/packs/" with a check that searches for the configured CDN hostname or full CDN
URL pattern in the rendered HTML; update the docs text and example command that
currently references "grep /packs/" so it instead greps (or uses a regex) for
your actual CDN host (e.g., the configured CDN domain or
"https://<your-cdn-host>") to ensure asset tags include the CDN host rather than
just matching relative "/packs/" paths.
In `@docs/troubleshooting.md`:
- Around line 257-271: The Gemfile and package.json version specifiers for
shakapacker allow different ranges which can lead to mismatched releases; update
the Gemfile's gem 'shakapacker' specifier and the package.json "shakapacker"
dependency so they express the same compatible range (e.g., change gem
'shakapacker', '~> 9.1' to '~> 9.1.1' and change "shakapacker": "^9.1.1" to a
matching "~9.1.1", or alternatively use a shared broader constraint like '>=
9.1.1, < 9.2.0' in both places) to ensure the gem and npm package stay
synchronized.
In `@docs/v9_upgrade.md`:
- Around line 39-40: The documented NODE_ENV fallback is incorrect: update the
bullet that currently reads "When `RAILS_ENV` is unset or any other custom value
(staging, qa, etc.) → `NODE_ENV` defaults to \"production\"" so it reflects the
actual runtime logic by replacing `"production"` with `"development"` (i.e.,
change that text to indicate NODE_ENV defaults to "development" for unset or
custom RAILS_ENV values).
🪄 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: 57a5c6ec-405a-493b-9e8e-b6d81f11cd1f
📒 Files selected for processing (22)
CLAUDE.mdCONTRIBUTING.mdREADME.mddocs/api-reference.mddocs/cdn_setup.mddocs/common-upgrades.mddocs/css-modules-export-mode.mddocs/deployment.mddocs/early_hints.mddocs/peer-dependencies.mddocs/precompile_hook.mddocs/react.mddocs/releasing.mddocs/rspack_migration_guide.mddocs/transpiler-migration.mddocs/troubleshooting.mddocs/typescript-migration.mddocs/using_esbuild_loader.mddocs/using_swc_loader.mddocs/v9_upgrade.mdpackage/types/README.mdspec/dummy/README.md
| **Solution:** This was fixed in Shakapacker v9.1.1+. Upgrade both the gem and npm package to the same version: | ||
|
|
||
| ```ruby | ||
| # Gemfile | ||
| gem 'shakapacker', '~> 9.1' | ||
| ``` | ||
|
|
||
| ```json | ||
| // package.json | ||
| { | ||
| "dependencies": { | ||
| "shakapacker": "^9.1.1" | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Version specifier mismatch between gem and npm package.
The documentation states to "upgrade both the gem and npm package to the same version," but the version specifiers allow different version ranges:
- Gemfile
~> 9.1allows only 9.1.x (e.g., 9.1.0, 9.1.1, 9.1.5) - package.json
^9.1.1allows any 9.x.x (e.g., 9.1.1, 9.2.0, 9.3.0)
This could result in mismatched versions (e.g., gem at 9.1.5, npm at 9.2.0), defeating the purpose of keeping them synchronized.
🔧 Proposed fix to align version specifiers
Option 1 (Recommended): Use compatible version ranges for both
```ruby
# Gemfile
-gem 'shakapacker', '~> 9.1'
+gem 'shakapacker', '~> 9.1.1'// package.json
{
"dependencies": {
- "shakapacker": "^9.1.1"
+ "shakapacker": "~9.1.1"
}
}
Option 2: Use broader range for both (if intentional)
```diff
```ruby
# Gemfile
-gem 'shakapacker', '~> 9.1'
+gem 'shakapacker', '~> 9.1', '>= 9.1.1'
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against the current code and only fix it if needed.
In @docs/troubleshooting.md around lines 257 - 271, The Gemfile and package.json
version specifiers for shakapacker allow different ranges which can lead to
mismatched releases; update the Gemfile's gem 'shakapacker' specifier and the
package.json "shakapacker" dependency so they express the same compatible range
(e.g., change gem 'shakapacker', '> 9.1' to '> 9.1.1' and change
"shakapacker": "^9.1.1" to a matching "~9.1.1", or alternatively use a shared
broader constraint like '>= 9.1.1, < 9.2.0' in both places) to ensure the gem
and npm package stay synchronized.
</details>
<!-- fingerprinting:phantom:triton:puma -->
<!-- This is an auto-generated comment by CodeRabbit -->
| - When `RAILS_ENV` is unset or any other custom value (staging, qa, etc.) → `NODE_ENV` defaults to `"production"` | ||
|
|
There was a problem hiding this comment.
NODE_ENV fallback behavior is documented incorrectly here.
For unset or custom RAILS_ENV values, current logic defaults NODE_ENV to "development", not "production". Please fix this bullet to match runtime behavior.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/v9_upgrade.md` around lines 39 - 40, The documented NODE_ENV fallback is
incorrect: update the bullet that currently reads "When `RAILS_ENV` is unset or
any other custom value (staging, qa, etc.) → `NODE_ENV` defaults to
\"production\"" so it reflects the actual runtime logic by replacing
`"production"` with `"development"` (i.e., change that text to indicate NODE_ENV
defaults to "development" for unset or custom RAILS_ENV values).
| rescue Shakapacker::Configuration::InvalidConfigurationError => e | ||
| Rails.logger.error "Invalid config: #{e.message}" | ||
| Shakapacker.config.fetch(:unknown_key) | ||
| rescue KeyError => e |
There was a problem hiding this comment.
Bug: config.fetch won't raise KeyError for unknown keys.
Shakapacker::Configuration#fetch is implemented as:
def fetch(key)
data.fetch(key, defaults[key])
enddefaults is a HashWithIndifferentAccess — accessing an unknown key on it returns nil, not a KeyError. So config.fetch(:unknown_key) returns nil silently rather than raising. The original example was also wrong (InvalidConfigurationError doesn't exist in the codebase), but the replacement is equally incorrect. Consider removing this example or replacing it with an error condition that actually occurs.
|
Overall this PR is a solid docs cleanup. One factual error is flagged inline on docs/api-reference.md line 460. Positive callouts: swc.config.js options wrapper fix aligns with using_swc_loader.md; symbol key corrections for config.data are accurate; removing non-existent API methods (status_url, asset_url, last_compilation_digest, CompilationError etc) is good cleanup; manifest.refresh return value is correctly documented; CDN manifest clarification is accurate; NODE_ENV behaviour fix in v9_upgrade.md matches the actual source code; rake task -- separator matches the task documented usage. |
e7fd841 to
88c4464
Compare
| **Solution:** This was fixed in Shakapacker v9.1.1+. Upgrade to the latest version: | ||
| **Solution:** This was fixed in Shakapacker v9.1.1+. Upgrade both the gem and npm package to the same version: | ||
|
|
||
| ```ruby |
There was a problem hiding this comment.
The Gemfile specifier ~> 9.1 expands to >= 9.1.0, < 10, so it would allow installing 9.1.0 — which is the version that doesn't have the fix. Since the section heading says "fixed in v9.1.1+", the minimum should be pinned to 9.1.1:
| ```ruby | |
| gem 'shakapacker', '~> 9.1', '>= 9.1.1' |
Or if a tighter patch pin is preferred:
| ```ruby | |
| gem 'shakapacker', '~> 9.1.1' |
Either way the intent should match the ^9.1.1 floor used in the package.json example below.
| 2. Clear Rails cache: `bundle exec rake tmp:cache:clear` | ||
| 3. Check the manifest.json file includes CDN URLs: | ||
| 3. Check your rendered asset tags use the CDN host. The manifest intentionally stores pack paths without the CDN host: | ||
| ```bash |
There was a problem hiding this comment.
The new command still greps for /packs/, which will match whether or not the CDN is in use (every app will have /packs/ paths). This doesn't verify that the CDN host appears in the rendered HTML.
A more meaningful check would grep for the configured CDN hostname:
| ```bash | |
| curl -s https://your-app.example.com | grep "your-cdn-host.example.com" |
Replace your-cdn-host.example.com with the actual value of SHAKAPACKER_ASSET_HOST / config.action_controller.asset_host. This fails loudly if the CDN host is absent from the rendered asset tags, which is exactly what the troubleshooting step is meant to catch.
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/troubleshooting.md (1)
257-269:⚠️ Potential issue | 🟠 MajorVersion constraints still contradict the “same version” guidance.
Line 257 says both dependencies should be the same version, but Line 261 (
~> 9.1) and Line 268 (^9.1.1) allow different ranges and can drift.🔧 Suggested doc fix
# Gemfile -gem 'shakapacker', '~> 9.1' +gem 'shakapacker', '~> 9.1.1'{ "dependencies": { - "shakapacker": "^9.1.1" + "shakapacker": "~9.1.1" } }Based on learnings: "Be aware of the dual package.json/Gemfile dependency management in Shakapacker".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/troubleshooting.md` around lines 257 - 269, The docs currently recommend "the same version" but show Gemfile using ~> 9.1 and package.json using ^9.1.1 which allow different ranges; update the example to pin the identical Shakapacker version in both manifests (replace Gemfile's gem 'shakapacker', '~> 9.1' and package.json's "shakapacker": "^9.1.1" with the same exact version string, e.g. '9.1.1', so both Gemfile and package.json reference the exact same release).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/troubleshooting.md`:
- Around line 257-269: The docs currently recommend "the same version" but show
Gemfile using ~> 9.1 and package.json using ^9.1.1 which allow different ranges;
update the example to pin the identical Shakapacker version in both manifests
(replace Gemfile's gem 'shakapacker', '~> 9.1' and package.json's "shakapacker":
"^9.1.1" with the same exact version string, e.g. '9.1.1', so both Gemfile and
package.json reference the exact same release).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 95c14161-d248-41cb-91c2-80c8d9af170a
📒 Files selected for processing (22)
CLAUDE.mdCONTRIBUTING.mdREADME.mddocs/api-reference.mddocs/cdn_setup.mddocs/common-upgrades.mddocs/css-modules-export-mode.mddocs/deployment.mddocs/early_hints.mddocs/peer-dependencies.mddocs/precompile_hook.mddocs/react.mddocs/releasing.mddocs/rspack_migration_guide.mddocs/transpiler-migration.mddocs/troubleshooting.mddocs/typescript-migration.mddocs/using_esbuild_loader.mddocs/using_swc_loader.mddocs/v9_upgrade.mdpackage/types/README.mdspec/dummy/README.md
✅ Files skipped from review due to trivial changes (12)
- docs/early_hints.md
- docs/typescript-migration.md
- docs/v9_upgrade.md
- CLAUDE.md
- docs/deployment.md
- docs/using_swc_loader.md
- package/types/README.md
- docs/cdn_setup.md
- docs/css-modules-export-mode.md
- docs/using_esbuild_loader.md
- docs/peer-dependencies.md
- README.md
🚧 Files skipped from review as they are similar to previous changes (7)
- docs/common-upgrades.md
- spec/dummy/README.md
- docs/releasing.md
- docs/precompile_hook.md
- docs/rspack_migration_guide.md
- docs/react.md
- CONTRIBUTING.md
Review: Fix stale and broken documentationOverall this is a well-scoped docs clean-up. Most of the factual corrections are verified against the source code and accurate:
Two concrete issues flagged inline:
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/react.md (1)
19-19: Consider tightening wording in the “manual setup” caveat.“very simple” is a bit vague; replacing it with “basic” or “minimal” reads more crisply in docs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/react.md` at line 19, Update the caveat sentence that reads "This manual setup is best for very simple React usage." to use a crisper adjective such as "basic" or "minimal" (e.g., "This manual setup is best for basic React usage."), so replace "very simple" with the chosen word in the same sentence in the docs content.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/react.md`:
- Line 19: Update the caveat sentence that reads "This manual setup is best for
very simple React usage." to use a crisper adjective such as "basic" or
"minimal" (e.g., "This manual setup is best for basic React usage."), so replace
"very simple" with the chosen word in the same sentence in the docs content.
…pass-1 * origin/main: Allow webpack-cli v7 in peer dependencies (#1021) # Conflicts: # docs/peer-dependencies.md
| ```ruby | ||
| # Gemfile | ||
| gem 'shakapacker', '~> 9.1' | ||
| gem 'shakapacker', '~> 9.1.1' |
There was a problem hiding this comment.
The surrounding text says "This was fixed in Shakapacker v9.1.1+", but ~> 9.1 allows 9.1.0 (the unfixed release) — it's equivalent to >= 9.1.0, < 10.0. The npm side correctly uses ^9.1.1.
| gem 'shakapacker', '~> 9.1.1' | |
| gem 'shakapacker', '~> 9.1.1' |
| 3. Check your rendered asset tags use the CDN host. The manifest intentionally stores pack paths without the CDN host: | ||
| ```bash | ||
| cat public/packs/manifest.json | ||
| curl -s https://your-app.example.com | grep cdn.example.com |
There was a problem hiding this comment.
This check is misleading. grep /packs/ matches whether CDN is configured or not — assets always reference /packs/ paths in the manifest (as the docs note, the manifest stores paths without the CDN host). The grep will pass even when CDN is not working.
To actually verify CDN is in use, grep for the CDN host in rendered <script>/<link> tags:
| curl -s https://your-app.example.com | grep cdn.example.com | |
| curl -s https://your-app.example.com | grep 'your-cdn-host.example.com' |
Replace your-cdn-host.example.com with the configured SHAKAPACKER_ASSET_HOST value.
|
Review posted with 2 inline comments. Summary: docs/troubleshooting.md:261 needs tilde constraint fixed (~> 9.1 -> ~> 9.1.1), and docs/cdn_setup.md:210 grep command needs to check CDN hostname not /packs/ path. NODE_ENV claim in v9_upgrade.md is correct (CodeRabbit was wrong). |
Documentation ReviewVerified all API examples against the current source code. The corrections are accurate and the overall quality is high. Verified correct:
One behavioral change to be aware of:
Minor nit:
|
| // Override v9 default to use v8-style default exports | ||
| cssLoaderUse.options.modules.namedExport = false | ||
| cssLoaderUse.options.modules.exportLocalsConvention = "asIs" | ||
| cssLoaderUse.options.modules.exportLocalsConvention = "camelCase" |
There was a problem hiding this comment.
This change from "asIs" → "camelCase" is actually correct — Shakapacker's built-in css_modules_export_mode: default (Option 1) sets exportLocalsConvention: 'camelCase', so this makes Option 2 consistent with it.
Worth noting the behavioral difference for anyone reading this: with "asIs", only the literal class name is exported (styles["my-button"]), while "camelCase" also adds a camelCase alias (styles.myButton). Users who were relying on the old Option 2 example specifically to suppress camelCase aliasing should use "asIs" instead.
Consider adding a one-line note to the section, e.g.:
Use
"asIs"instead if you want class names exported exactly as written with no camelCase aliases.
* origin/main: (22 commits) docs: add Dependabot configuration guide (#1094) Sync address-review prompt with upstream PR #16 (#1098) Supersede #910: entry shape test with lint unblock (#919) fix: align rspack v2 peer deps and installer defaults (#1091) docs: update README and guides for Shakapacker v10 (#1092) Release 10.0.0 Update CHANGELOG.md for v10.0.0 (#1089) Release 10.0.0-rc.1 Update CHANGELOG.md for v10.0.0-rc.1 (#1087) Supersede #961 by using pack-config-diff (#973) Add final summary output to rake release (#1041) Add bin/setup to install development deps (#1039) Release 10.0.0-rc.0 Use npx release-it to avoid mise shim failures (#1040) Fix Nokogiri build failure on Ruby 3.4.6 (#1038) Update CHANGELOG.md for v10.0.0-rc.0 (#1037) Update rspack dev deps to 2.0.0-rc.0 (#1036) Fix stale and broken documentation across Shakapacker guides (#1023) Allow webpack-cli v7 in peer dependencies (#1021) refactor: simplify resolving js peer versions when installing (#1034) ... # Conflicts: # package.json
Summary
Verification
git diff --checkyarn prettier --writeon changed docs filesNotes
Note
Low Risk
Low risk: documentation-only updates, but incorrect guidance could still confuse users if any command/version claims are wrong.
Overview
Documentation overhaul across core guides to align with current Shakapacker behavior and tooling, including updated Node.js baseline (Node 20+) and clearer guidance on optional peer dependencies and installer behavior.
Updates API/reference and migration docs to match current config/return shapes and workflows (e.g., symbol-keyed config data, refreshed manifest/dev-server/compiler examples), and replaces outdated commands with current
bundle exec rake/bin/raketask usage.Fixes broken links/anchors and refreshes several setup guides (React, TypeScript, CDN verification, Heroku deploy, releasing), including simplified React + SWC/Babel notes, TypeScript install/type-check recommendations, and updated peer dependency ranges/examples.
Written by Cursor Bugbot for commit 4bf06f1. This will update automatically on new commits. Configure here.
Summary by CodeRabbit