Walkthrough

Raised webpack minimum to ^5.101.0, added ^7.0.0 support for webpack-cli, constrained webpack-dev-server to ^5.2.2 across manifests and docs; bumped dev webpack to 5.101.3; adjusted CI workflow quoting and TypeScript flags; renamed several Jest mock constructors in a test; added CHANGELOG entry.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 I hopped through packages, nudged versions anew,
Welcomed v7 and tightened a few,
Docs and CI polished, mocks given names,
A small carrot of change—no tangled snares or blames. 🥕

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 extends the webpack-cli peer dependency range in package.json from ^4.9.2 || ^5.0.0 || ^6.0.0 to ^4.9.2 || ^5.0.0 || ^6.0.0 || ^7.0.0, keeping docs/peer-dependencies.md and CHANGELOG.md in sync. The change is minimal and consistent across all three files.

Key points to be aware of:

• webpack-cli v7 dropped webpack-dev-server@v4 support — users combining webpack-cli@v7 with webpack-dev-server@v4 (still in the peer dep range as ^4.15.2) will hit runtime failures with the dev server. A compatibility note in the docs is recommended.
• webpack-cli v7 requires webpack >= 5.82.0 — the current webpack peer dep allows as low as ^5.76.0, which could cause issues for users on older webpack patch versions.
• devDependency still pinned to ^6.0.0 — CI is not yet exercising the newly permitted v7, consistent with the unchecked "CI passes" item in the PR description.

Confidence Score: 4/5

• Safe to merge with a few follow-up compatibility notes recommended before the next release.
• The change itself is a one-line peer dep range extension, consistently applied across package.json, docs, and CHANGELOG. The main outstanding item is that CI hasn't been verified against webpack-cli v7, and there are two cross-peer-dep compatibility edge cases (webpack-dev-server v4 and webpack < 5.82.0) worth documenting. None of these block the primary user path of simply adding ^7.0.0 support.
• package.json — the devDependency and cross-peer-dep compatibility constraints deserve a second look before release.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User installs shakapacker] --> B{Which webpack-cli version?}
    B --> C[v4 / v5 / v6]
    B --> D[v7 - NEW in this PR]
    C --> E[Works with webpack-dev-server v4 or v5]
    D --> F{Which webpack-dev-server?}
    F --> G[v5 - OK]
    F --> H[v4 - Runtime failure\nwds@v4 dropped in cli@v7]
    D --> I{Which webpack version?}
    I --> J[>= 5.82.0 - OK]
    I --> K[5.76 - 5.81 - May fail\ncli@v7 requires >= 5.82.0]

_{Reviews (1): Last reviewed commit: "Allow webpack-cli v7 in peer dependencie..." | Re-trigger Greptile}

Review

The core change is correct. Two gaps worth fixing before merge:

1. lib/install/package.json not updated (important)

Line 12 still reads webpack-cli: ^4.9.2 || ^5.0.0 || ^6.0.0 - missing ^7.0.0. This is the template used by the install generator, so new projects will not get v7 support. Should be updated to include || ^7.0.0.

2. lib/shakapacker/doctor.rb stale version string (minor)

Line 277 reads webpack-cli => ^4.9.2 || ^5.0.0. This appears in the missing dependency warning and is already missing v6 and now v7. Does not affect validation logic but is misleading. Worth updating to match the full supported range.

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Two gaps worth fixing before merge. (1) lib/install/package.json line 12 still reads webpack-cli ^4.9.2 || ^5.0.0 || ^6.0.0 - this is the template used by rails shakapacker:install so new projects will not get v7. (2) lib/shakapacker/doctor.rb line 277 has the stale string webpack-cli => ^4.9.2 || ^5.0.0 in the missing-dependency warning shown to users - it already missed v6 and now misses v7. Worth noting: devDependencies is still ^6.0.0 so CI is not exercising v7 yet.

Addressed the follow-up compatibility items in this PR as well:

• Updated installer metadata (lib/install/package.json) to include webpack-cli v7.
• Raised webpack peer minimum to ^5.101.0 and webpack-dev-server to ^5.2.2 in package.json, installer metadata, and peer dependency docs.
• Updated doctor guidance (lib/shakapacker/doctor.rb) so reported essential webpack ranges match current support (webpack ^5.101.0, webpack-cli ^4 || ^5 || ^6 || ^7).
• Updated development/test dependency coverage by moving root devDependency to webpack-cli ^7.0.0 (with webpack 5.101.3) and moving the dummy app to webpack-cli ^7.0.0.
• Synced lockfiles (yarn.lock and spec/dummy/yarn.lock).

This should close out the remaining compatibility concerns raised in review.

Review summary posted as inline comments. See discussion threads on CHANGELOG.md, README.md, docs/v9_upgrade.md, test/package/bundlerUtils.rspack.test.js, and .github/workflows/trigger-docs-site.yml for specifics.

Review: Allow webpack-cli v7 in peer dependencies

The core change is straightforward and well-executed. A few issues worth addressing:

Breaking change: webpack-dev-server v4 dropped without documentation

The range changed from ^4.15.2 || ^5.2.2 to just ^5.2.2, silently dropping v4 support. This should be called out in the changelog — users on webpack-dev-server v4 will get peer dependency warnings that are not currently explained.

Node.js version implication not documented

webpack-cli v7 requires Node >= 20.9.0 (its commander v14 dependency enforces this). The CI matrix already tests only Node 20.x and 22.x, so CI is fine, but consumers on Node 18 LTS would be broken by upgrading to webpack-cli v7. This minimum Node version requirement is not mentioned in the changelog, docs, or peer dependency documentation.

README and upgrade docs still show stale version examples

README.md (lines ~259-260 and ~277-278) and docs/v9_upgrade.md (lines ~341-342) still show webpack-cli ^5.0.0 and webpack-dev-server ^5.0.0 in their example snippets, inconsistent with the updated peer dependency ranges.

--ignoreDeprecations 6.0 suppresses warnings rather than fixing them

The TypeScript flag added to the CI type-check job silences TypeScript 6.0 deprecation warnings instead of resolving them. This is fine as a short-term workaround (--moduleResolution node is deprecated in favour of bundler), but worth a follow-up issue to migrate the .d.ts type-check to a supported resolution mode.

Code Review

Thanks for the PR. The implementation is generally solid. A few issues worth addressing before merge:

Documentation inconsistency — webpack-cli v7 shown without Node caveat

docs/optional-peer-dependencies.md shows webpack-cli ^7.0.0 in its Webpack+Babel and Webpack+SWC examples with no Node.js version caveat. This contradicts the README (which recommends ^6.0.0 and notes v7 requires Node >= 20.9.0) and the installer (which defaults to v6). Users on Node 20.0-20.8 following those docs will hit install failures with no guidance. The examples should either use ^6.0.0 or include the same Node caveat as the README.

CI node version vs. declared engine floor

dummy.yml pins node-version 20 but spec/dummy/package.json now declares node >=20.9.0. In practice GitHub Actions resolves 20 to the latest 20.x so CI passes today. But pinning to at least 20.9 would make the constraint explicit and avoid surprises if the runner image ever changes.

Installer always selects v6 regardless of actual Node version

The template.rb logic pattern-matches on the constraint string and always picks v6, even when the user is on Node >=20.9.0. This is intentionally conservative, but users on modern Node who want v7 must know to manually upgrade. The installer output or upgrade docs should note that users on Node >=20.9.0 can pin webpack-cli ^7.0.0 themselves.

All three items addressed in e899119:

1. Docs inconsistency — Changed optional-peer-dependencies.md examples to use ^6.0.0 (matching README) and added a Node >= 20.9.0 caveat note for v7.

2. CI node version — Pinned dummy.yml node-version from "20" to "20.9" to match spec/dummy/package.json's >=20.9.0 engine floor.

3. Installer hint — The installer now prints an info message when it selects webpack-cli v6, telling users on Node >= 20.9.0 they can manually upgrade to v7.

Code Review - PR 1021

The core addition (expanding webpack-cli peer dep to include ^7.0.0) is clean, the deprecation-warning helper is well-structured, and the new Jest tests are a good addition. A few issues worth addressing:

1. doctor.rb does not warn about dropped webpack-dev-server v4 support

The PR drops ^4.15.2 from the webpack-dev-server peer range (a breaking change), but check_webpack_peer_deps in doctor.rb never checks which version of webpack-dev-server is installed. A user who still has v4 after upgrading will get confusing runtime errors with no doctor guidance. Consider adding webpack-dev-server => ^5.2.2 to the essential_webpack hash, or at minimum a version-range check that warns when v4 is detected.

2. Hardcoded ^6. string in lib/install/template.rb

The fallback logic uses constraint.start_with?('^6.'). This is tightly coupled to the current constraint format - if the string ever has a different prefix style, the find silently falls through to selected_version (v7), which is the opposite of the intended safe default. Using the full exact string '^6.0.0' would be more precise, and a comment explaining the fallback behaviour would help future maintainers.

3. Scope of breaking changes vs. version policy

This PR bundles three breaking changes: minimum webpack bumped from ^5.76.0 to ^5.101.0, webpack-dev-server v4 dropped, and installer defaults changed. These are documented in CHANGELOG.md (good), but worth confirming whether the project semver policy requires a new major version, or whether they roll into the current minor. The PR title only mentions the webpack-cli v7 addition, which understates the impact.

4. spec/dummy/package.json engine requirement is overly specific

Bumping engines.node from >=18.0.0 to >=20.9.0 prevents contributors on Node 20.0-20.8 from running dummy integration tests even though webpack-cli v6 (the new installer default) works fine on those versions. The installer v6 fallback exists precisely to support broad Node 20.x compatibility - this constraint works against that goal. Consider >=20.0.0 instead.

Code Review: Allow webpack-cli v7 in peer dependencies

The overall direction is good. The CHANGELOG correctly marks the WDS v4 drop and webpack minimum bump as breaking. A few things worth noting:

1. Hardcoded ^6. string match in installer (lib/install/template.rb:271)

The constraints.find { |c| c.start_with?("^6.") } check is brittle. If a future PR adds ^8.0.0 to the range, this logic will still silently default to v6. The rationale (prefer v6 for Node 20.0-20.8 compat) won't stay valid as the ecosystem ages. At minimum, a comment here flagging that this sentinel needs manual review when peer dep ranges change would prevent a silent regression.

2. Test assertions in webpackDevServerConfig.test.js check keys that would never have been set (lines 26-27)

expect(config.onBeforeSetupMiddleware).toBeUndefined() and expect(config.onAfterSetupMiddleware).toBeUndefined() pass trivially regardless of this PR — those camelCase keys were already absent from webpackDevServerMappedKeys before this change. The assertions don't exercise the new behavior (warning and deletion of deprecated snake_case keys). More meaningful would be asserting config.on_before_setup_middleware and config.on_after_setup_middleware are undefined, since those are the actual keys that now get deleted. The warning assertions are good and should stay.

3. spec/dummy/package.json engines raised to >=20.9.0

The dummy app now requires Node >= 20.9.0 (up from >= 18.0.0) because it pins webpack-cli v7. The main docs recommend v6 by default (Node 20.0+), so there is now a split between what the docs say and what the dummy app requires. Users copying the dummy app as a starting point may be confused.

4. node-version: "20.x" in CI vs the new engine floor

With spec/dummy/package.json requiring >=20.9.0, using "20.x" in the workflow resolves to the latest 20.x today, so it works. But using "20.9" or ">=20.9" would express the intent more precisely and guard against any runner that might resolve to an older 20.x patch.