I recently launched an upgrade to Blue Bottle's core Rails application that enabled Weback and Yarn to respectively handle bundling/transpilation and third-party dependencies. It's been a goal for a while to see ES6+ code in production and as of yesterday, JS code is now in production that was transpiled with Babel and utilizes classes, module import/export and arrow functions 🎉.

This was made possible by the Webpacker gem that makes installing and configuring Webpack in a Rails application as straightforward as possible. I started working on the Webpacker integration last year but had to pause to work on other projects. In the interim, Webpacker 3.0 was released, hiding much of the stock configuration and eliminated the need for a separate process to run bin/webpack locally, very welcome additions. With the release of the 3.0, the Rails team hinted that Webpacker we could see might tighter integration between Rails and Webpack moving forward:

"Webpacker 3.0 points to what a Webpack-by-default strategy could look like in Rails 6.0. One where the asset pipeline focuses on static assets, like images, fonts, sounds, and compiled CSS, using SASS and so on, but bows out of the JavaScript compilation game. We still haven’t pinned the final approach, but this is our best current take on how the two could split the workload of dealing with JavaScript, stylesheets, and other assets in the next big Rails release."

Along with Webpack, our main app is now using Yarn for select JS dependencies. This is something I've wanted to see for a while, as we were previously using Rails-Assets, which went down last year and didn't seem reliable enough to use as our core JS dependency manager, on top of the non-ideal situation of having to mix Ruby and JS libraries within our Gemfile. Yarn makes it easy to lock versions and the new Yarn integrity check makes it much easier to catch a missed Yarn install.