Hacker News new | ask | show | jobs
by verisimilidude 3405 days ago
This is pretty great. Since hopping back onto Rails about six months ago, I've made a habit out of removing the asset pipeline from every new project in favor of webpack and Yarn. It always feels a little cobbled together, but worth the trouble to take full advantage of the JS ecosystem. Having these tools as a native part of Rails will hopefully make my own workflow a bit more streamlined. Looking forward to it.
1 comments

How do you handle versioning of the compiled assets and linking to them from the view? `<%= javascript_tag 'foo' %>` is the main benefit of the asset pipeline to me, so they can be long-expiring and busted with any change.

I, too, agree that the asset pipeline is clunky. But at my startup we went the other way: use npm/webpack but compile the resulting file _into_ the assets directory, so we can still use the asset pipeline. It sort of double processes the assets but it was the only way I could think of to take advantage of modern JS with imports and exports, and still get the cache-busting goodness and easy rails view interoperability.

You can use a plugin like assets-webpack-plugin [0] to get a JSON file that maps to the compiled file names. That's basically the same thing asset pipeline would do.

Here's a blog post [1] explaining how to use webpack with rails.

[0] https://github.com/kossnocorp/assets-webpack-plugin

[1] http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#...

It's pretty easy to do - have your build tool generate a hash of the bundle and store that (simplest way is a json file with the file:hash as a key:value, obv other ways are possible)

Webpack has built in support for this as it generates chunk hashes and can output filenames with them in it, then you just get that data and do the same as above.

How you put that in your Rails app is up to you - could be a simple helper like javascript_tag, that would be easy to do.

Rails really didn't have any magic to the asset pipeline in that regard.

abritinthebay's answer is the same thing I'm doing. Webpack can give you a hash on each use, which allows you to:

* add that hash to the filename(s) of your generated assets;

* print out that hash to a file;

* fetch the hash from that file for use in your helpers/views, to call the correct assets.

The following blog post is a good place to get started.

http://pixelatedworks.com/articles/replacing-the-rails-asset...

Whether or not this is better or worse than your current setup, I'm not sure. It's probably equal levels of duct tape either way. Printing out the hash and rolling your own solution gives you a bit more power and flexibility though.