If your web application runs on Ruby on Rails and has been around for a few years, there's a good chance it still relies on Webpacker. For years, it was the standard tool for bundling the JavaScript and stylesheets of a Rails application. The problem: Webpacker is officially deprecated. No more fixes, no more security updates, no more guaranteed compatibility with newer versions of Rails. Every month that passes turns this dependency into technical debt that will cost you dearly the day it breaks.

The good news: the escape route exists, it's official, and it makes your application lighter along the way. It's called esbuild, delivered through the jsbundling-rails package. Here's what that means for you, without the jargon.

What Webpacker is, and why it's a problem today

When a user opens your site, their browser doesn't directly understand the code your developers wrote. It first has to be compiled and grouped into optimized files: that's the job of a "bundler." Webpacker was the default bundler for Rails between 2017 and 2021. Thousands of applications still use it.

The trouble is that the Rails team stopped maintaining it. In practical terms, an abandoned dependency creates three problems that always end up catching up with you. First, security: the flaws discovered in its components are no longer fixed. Next, compatibility: the moment you want to update Rails, Ruby, or any other building block, Webpacker becomes the sticking point. Finally, the human cost: fewer and fewer developers know how to troubleshoot it, and its configuration is notoriously heavy and fragile. One harmless-looking change can break an entire deployment.

esbuild: faster, simpler, and still supported

esbuild does the same job as Webpacker, but differently. It's a modern tool, written in a compiled language, which makes it spectacularly fast: where Webpacker sometimes took several minutes to prepare the files, esbuild often finishes in under a second. For your developers, that means near-instant feedback loops. For you, it means shorter, lower-risk deployments.

Integration goes through jsbundling-rails, a package officially maintained by the Rails team. That matters: you're not trading an abandoned dependency for an uncertain bet, you're adopting the path Rails recommends and keeps alive. The configuration fits in a few lines, versus the dense Webpacker files that almost no one dared touch. Less configuration mechanically means less surface for things to break.

What the migration changes concretely for you

The reassuring part first: for your users, nothing changes visually. The site does exactly the same thing, displays the same way, behaves the same way. The migration is purely internal — we replace the machinery under the hood, not the bodywork.

What changes is the health of your application. You're leaving a dead dependency behind, so you close off an entry point for security problems. You unlock future Rails updates that Webpacker was holding hostage. You speed up the work of anyone who touches the code after you, even for simple fixes. And you reduce the risk with every deployment, because a simple configuration breaks less often than an over-engineered contraption.

In practical terms, the switch is typically done all at once, on a test copy of the application, before being validated and then put into production. We check that every page, every interaction, every script keeps working exactly as before. It's a well-bounded job, with no gray area: either everything works as before, or we fix it before shipping.

How long, how much it costs

For a medium-sized application, migrating from Webpacker to esbuild is a job of a few days, not a few weeks. The difficulty depends mainly on the amount of custom JavaScript and the degree of tinkering accumulated in the old configuration. A "standard" application migrates quickly; an application with a lot of custom code requires more checking.

This is exactly the kind of work we handle at a fixed price: we look at your application, we give you a clear amount and timeline, and we deliver a tested application, with no surprises on the invoice. You're not paying a developer by the hour for a job with an uncertain scope — you're buying a verified result.

Don't wait for the breakdown

An abandoned dependency makes no noise… until the day an update becomes mandatory and everything grinds to a halt at once. At that point, the intervention becomes an emergency, so it's more expensive and more stressful. Migrating now, while everything works, turns a future breakdown into a simple, planned line of maintenance.

If your Rails application still relies on Webpacker and you want to know where you stand, we can take stock. Discover our approach to taking over and upgrading applications, take a look at our fixed-price rates, or browse other resources on modernizing web applications.