Webpack Integration with a Gem

Rails
1

@zts wrote:

Have you considered turning this into a gem?

It’s definitely worth considering. Let’s discuss this!

There’s a couple ways we could go:

  1. Generator: We could have a simple generator to create the directories, the config files, etc. This just saves some time for a new project.
  2. Webpack in Sprockets: We could have Webpack work like browserify-rails. This would change the way that sprockets handles assets.

What is the criteria for success?

  1. Ease of use for beginners so that they could get the basic essentials of webpack without fully needing to understand all the configuration nuances.
  2. Ease of use to prototype JS code using the Webpack Dev Server.
  3. No need to remember to run ‘webpack -w’ to automatically rebuild the bundle.js file.
  4. Simpler deployment to places like Heroku.
  5. Ability to integrate existing gems and legacy JavaScript and CoffeeScript code.

One thing that I find important is that the current mechanism makes it dead simple in terms of understanding what’s going on with WebPack. The problem with highly automated “wizards” is that when one wants to make an extension to the default configuration, then there’s a big learning curve. However, I do think the ability to get the benefits of this setup by following a few simple conventions would have great appeal.

Let’s discuss!

2

I like this idea a lot!

Maybe try both and see what sticks? :smile:

I think there’s a lot of flexibility with the generator route, and it definitely would be simple and easier to do. It could generate some sane defaults for the user and if they want to customize it, they would be free to do so. Since we are already adding npm into the mix, it may make sense to not try to integrate too heavily with Sprockets. I like the simplicity of letting webpack build the bundles and then passing to Sprockets for the fingerprinting and etc.

However, what are your ideas for integrating with Sprockets? Would the webpack server still be running or would a command just be run to compile the assets?

Also, it seems like in the future Sprockets may be able to handle transformations: https://github.com/sstephenson/sprockets/issues/607 and hopefully… eventually CommonJS: https://github.com/sstephenson/sprockets/issues/298, so it may just make more sense to go with the generator route?

3

I’d rank “Ease of use for beginners so that they could get the basic essentials of webpack” pretty high.

However, I’m still a bit confused personally about using both webpack and sprockets. It feels odd to me. In the ideal world, wouldn’t you just want to swap sprockets out and put in webpack in it’s place? (or am I missing some benefit to having both)

Obviously that’s not practical without an easy way to migrate existing projects over, but I find it useful to start with the ideal in mind…

I’ll have to try again the setup you blogged about.

4

In terms of sprockets and the asset pipeline, I’m mostly interested in just eliminating the following steps:

  1. Need to run webpack -w to build the rails-bundle.js
  2. Need to add custom rake task for precompiling for production.

While the Webpack ecosystem offers tons more that overlaps with the Rails Asset Pipeline (fingerprinting, minification, etc.), I’m not sure if there’s a compelling case to change those parts. Note, the Asset Pipeline was broken out into the sprockets gem.

The key features that make me want to use Webpack are:

  1. The JS loaders (es6 transpiler and JSX)
  2. The ability to quickly prototype JS code outside of Rails.