Background
PR #1096 ships the shakapacker-webpack and shakapacker-rspack supplemental packages for v10.1. spec/dummy/ continues to test the core gem against raw deps in package.json (with bin/test-bundler swapping config/shakapacker.yml to switch between webpack and rspack), and the wrapper packages have their own focused unit tests under test/packages/ (23 passing, including subprocess-isolated install resolution).
What's not covered today:
- The supplemental-package install path — does an app that adopts
shakapacker-rspack (or shakapacker-webpack) build cleanly end-to-end? test/packages/ exercises require.resolve and warning behavior in isolated subprocess fixtures, but not a real Rails dummy running through the full webpack/rspack build with the supplemental package as the install entry point.
- The custom-build path — apps that produce their own
manifest.json (Vite, hand-rolled webpack, esbuild) and use bare shakapacker only for the manifest reader / view helpers. This isn't tested anywhere in the dummy app today.
Proposed plan
Phase A: Supplemental-package coverage in spec/dummy
Pick one of the two approaches below; the working assumption is that we should soak the published 10.1 tarballs for a few weeks before making this change, so this lands after the 10.1 npm publish and works against shakapacker-webpack@~10.1.0 / shakapacker-rspack@~10.1.0 from the registry rather than local source.
Option A1 — Install both supplementals in the existing spec/dummy. yarn add --dev shakapacker-webpack shakapacker-rspack. npm hoists one shakapacker; both bundler stacks come along. bin/test-bundler keeps switching the YAML. The active-bundler mismatch will fire SHAKAPACKER_BUNDLER_MISMATCH for the wrong wrapper, so we'd either suppress with --no-warnings in the test runner or whitelist that warning code in CI assertions. Minimum diff; loses the "clean install" demonstration but keeps the existing matrix.
Option A2 — Add a second dummy app per bundler. spec/dummy-rspack-supplemental/ and spec/dummy-webpack-supplemental/ each install only the matching supplemental package, demonstrating the clean single-package install. CI grows from 2 jobs to 4. Cleanest separation; most maintenance.
Phase B: Custom-build coverage
New dummy app (e.g. spec/dummy-custom-build/) that:
- Installs bare
shakapacker (no supplemental package, no webpack/rspack peer deps).
- Has its own bundler script (probably Vite or hand-rolled esbuild — pick one for v1) that emits
public/packs/manifest.json in the format Shakapacker's manifest reader expects.
- Exercises the Rails view helpers (
javascript_pack_tag, stylesheet_pack_tag) reading from that manifest.
- Confirms
bin/shakapacker and bin/shakapacker-dev-server are not invoked (or fail clearly when invoked, since this is the custom-build path).
This is the missing test for the third documented user type in docs/migration/v10.1-supplemental-packages.md.
Acceptance criteria
Why this is a separate PR
Doing the dummy work in #1096 would have meant:
- More CI surface to land alongside the wrapper packages (slower review loop on a PR that's already large).
- Testing against unpublished local source instead of the actual published tarballs.
- Mixing "ship the new install model" with "validate the new install model in a real dummy app" — two different concerns.
By deferring, the follow-up PR can validate the published shakapacker-webpack@~10.1.0 and shakapacker-rspack@~10.1.0 tarballs end-to-end and catch any registry/install-resolution differences from local development.
References
Background
PR #1096 ships the
shakapacker-webpackandshakapacker-rspacksupplemental packages for v10.1.spec/dummy/continues to test the core gem against raw deps inpackage.json(withbin/test-bundlerswappingconfig/shakapacker.ymlto switch between webpack and rspack), and the wrapper packages have their own focused unit tests undertest/packages/(23 passing, including subprocess-isolated install resolution).What's not covered today:
shakapacker-rspack(orshakapacker-webpack) build cleanly end-to-end?test/packages/exercisesrequire.resolveand warning behavior in isolated subprocess fixtures, but not a real Rails dummy running through the full webpack/rspack build with the supplemental package as the install entry point.manifest.json(Vite, hand-rolled webpack, esbuild) and use bareshakapackeronly for the manifest reader / view helpers. This isn't tested anywhere in the dummy app today.Proposed plan
Phase A: Supplemental-package coverage in spec/dummy
Pick one of the two approaches below; the working assumption is that we should soak the published 10.1 tarballs for a few weeks before making this change, so this lands after the 10.1 npm publish and works against
shakapacker-webpack@~10.1.0/shakapacker-rspack@~10.1.0from the registry rather than local source.Option A1 — Install both supplementals in the existing
spec/dummy.yarn add --dev shakapacker-webpack shakapacker-rspack. npm hoists oneshakapacker; both bundler stacks come along.bin/test-bundlerkeeps switching the YAML. The active-bundler mismatch will fireSHAKAPACKER_BUNDLER_MISMATCHfor the wrong wrapper, so we'd either suppress with--no-warningsin the test runner or whitelist that warning code in CI assertions. Minimum diff; loses the "clean install" demonstration but keeps the existing matrix.Option A2 — Add a second dummy app per bundler.
spec/dummy-rspack-supplemental/andspec/dummy-webpack-supplemental/each install only the matching supplemental package, demonstrating the clean single-package install. CI grows from 2 jobs to 4. Cleanest separation; most maintenance.Phase B: Custom-build coverage
New dummy app (e.g.
spec/dummy-custom-build/) that:shakapacker(no supplemental package, no webpack/rspack peer deps).public/packs/manifest.jsonin the format Shakapacker's manifest reader expects.javascript_pack_tag,stylesheet_pack_tag) reading from that manifest.bin/shakapackerandbin/shakapacker-dev-serverare not invoked (or fail clearly when invoked, since this is the custom-build path).This is the missing test for the third documented user type in
docs/migration/v10.1-supplemental-packages.md.Acceptance criteria
.github/workflows/test-bundlers.ymlruns a passing job that builds with the supplemental package as the install entry point.manifest.jsonproduced by a non-Shakapacker bundler is read correctly by the gem and resolves through the view helpers.docs/dependency-strategy.mdunder §"Resolved Decisions" so future contributors know which testing model we picked and why.Why this is a separate PR
Doing the dummy work in #1096 would have meant:
By deferring, the follow-up PR can validate the published
shakapacker-webpack@~10.1.0andshakapacker-rspack@~10.1.0tarballs end-to-end and catch any registry/install-resolution differences from local development.References
test/packages/shakapacker-webpack/index.test.js,test/packages/shakapacker-rspack/index.test.js,test/packages/subpath-exports.test.js,test/packages/warning-codes.test.js