It strikes a great balance between the asset pipeline and webpacker.
jsbundling-rails is a much more lightweight integration.
This gem provides installers to get us going with the bundler of our choice in Rails application,
and a convention to use
app/assets/builds to hold our bundled output as artifacts.
The idea behind jsbundling is that we still use
Yarn and the
but the built bundle goes into the asset pipeline download rather than being controlled by webpack.
We must already have
yarn installed on our system.
We will also need
7.1.0 or later.
jsbundling-railsto Gemfile with
Or, in Rails 7+,
we can preconfigure our new application to use a specific bundler with
rails new myapp -j [esbuild|rollup|webpack].
The installer creates an
appends that directory to the asset pipeline manifest at
for our build script to be included in our application.
Run the bundler in watch mode in a terminal with
yarn build --watch.
Start dev server with
foreman start -f Procfile.dev or run
rails s and
yarn build --watch separately.
We can also use
which will start both the Rails server and the JS build watcher.
When we deploy our application to production,
to ensure that all our package dependencies from
package.json are installed via yarn,
and then runs yarn build to process all the entry points,
as it would in development.
The latter files are then picked up by the asset pipeline, digested,
and copied into
like any other asset pipeline file.
We can configure our bundler options in the
build script in
or via the installer-generated
webpack.config.json for Webpack.
One fantastic thing about
jsbundling-rails is even if we decide to use Webpack instead of esbuild
we can easily swap it out, and unlike Webpacker it will use a raw webpack config file.
That was a great decision because I imagine people who want to go all-in with Webpack will want to use their existing configs.
Comparison with webpacker
If we’re already using
we may be wondering how it compares to
and whether we should migrate or stick with
Here are some considerations:
jsbundling-railsis a much more lightweight integration.
webpackeris more involved and opinionated.
jsbundling-railscan be used with multiple bundlers (currently
webpackare supported out of the box, but anything that can put a bundle into
app/assets/buildscould be configured to work with it).
webpackeris built specifically to integrate with webpack.
webpackerreleases are tied to a specific major version of
babel, etc. This means we cannot freely upgrade those packages - we have to wait for a new
webpackermajor release that supports the newer versions, and upgrading to that new
jsbundling-railsuses the standard configuration format for our bundler of choice.
webpackerhas its configuration layer on top of webpack’s configuration, which requires us to do some translation when following guides/documentation written directly for webpack.
jsbundling-railsworks with the standard actionview asset helpers.
webpackerprovides the tag helpers that we need to use.
webpackercan be used as a complete replacement for sprockets, and in that setup, we can stop loading the sprockets/railtie in our application.
jsbundling-rails(as well as css-bundling-rails) works in conjunction with sprockets.
webpackersupports using a dev server for hot reloading.
webpackerdelegates asset processing entirely to the external nodejs tooling.
jsbundling-railsstill relies on sprockets to output the final public assets and create the associated manifest. When the webpack has full control over the result, it can integrate additional features like automatic code-splitting of statically imported shared dependencies, and
webpackercan load each entry point’s dependent chunks for us. With
jsbundling-rails, we’ll be able to manually split out lazy-loaded chunks by using dynamic import()s.
To know more about this feature checkout this PR.