What 'retired' does and does not mean
The Webpacker README says the project has been retired and that the Rails team will not develop it further in an official capacity, because Rails 7 removed the need for it in most cases. Existing users can keep running it unchanged. That is a reason to plan a decision, not an emergency: the risk grows as your Ruby, Node.js and bundler versions move away from what it supports.
- Retirement means no new official development, not that the app stops working.
- The README is the source for the status; check it before acting.
The three named options
The README names, in this order, jsbundling-rails with Webpack or another bundler, importmap-rails and the community project Shakapacker. jsbundling-rails supports Bun, esbuild, rollup.js and Webpack, writes its output to app/assets/builds and serves it through the asset pipeline. importmap-rails is the default for new Rails 7 apps and needs no build step, but the README warns that it can be a big jump depending on how much JavaScript you use. Shakapacker is community-led and builds on the unreleased next Webpacker version.
- Decide the target before choosing a Rails version step, not after.
- Do not assume one option supports every feature your build uses.
List what Webpacker does for you
Before choosing, inventory its jobs: each entry point, loaders for CSS, images or TypeScript, environment values read in the browser, code splitting and how the built files reach the page. The Rails guide favours import maps, particularly for Hotwire apps, and suggests a bundler for JSX, TypeScript, Webpack loaders or tree-shaking. An inventory tells you which side of that line your app is on.
- Count the entry points and the pages each one loads.
- Note anything the browser reads from environment settings; none of it may be secret.
- Note whether any code relies on Webpack-specific loaders.
What this means for the upgrade jobs
The fixed Rails 7 to 8.1 job does not replace the JavaScript build; it records which build you have and stops if the upgrade cannot proceed without changing it. A client-side single-page app built directly by Webpack, outside Rails, can move to Vite in a separate fixed job; Webpacker inside a Rails app is a different integration and is not covered by that job. An inventory and ranked plan can include the Webpacker decision as one of its steps.
- A Rails app on Webpacker and a standalone Webpack app need different jobs.
- Moving the build and upgrading Rails together make failures harder to read.
How a build change is accepted
Acceptance for a build change is page by page: every entry point loads on the pages that use it, the production asset build completes in your deployment pipeline, the JavaScript tests pass as before, and the agreed screens look and behave the same. Send the Rails and Ruby versions and the list of entry points, not the config files or any keys. Prices on the linked jobs are untested proposals with payment after agreed checks.
Sources and limits
- Webpacker README Checked 2026-10-11.
- The README says Webpacker has been retired, that the Rails team will not develop it further in an official capacity, and that existing users can keep running it unchanged.
- It names jsbundling-rails, importmap-rails and Shakapacker as alternatives, in that order.
- jsbundling-rails README Checked 2026-10-11.
- jsbundling-rails supports Bun, esbuild, rollup.js and Webpack, writes build output to app/assets/builds, and links to a guide for switching from Webpacker.
- Rails guides: working with JavaScript in Rails Checked 2026-10-11.
- Import maps are the default for new Rails 7 apps and need no build step; the guide suggests a bundler for JSX, TypeScript, Webpack loaders or tree-shaking.