In the last week, I’ve seen 2 other techniques for using Webpack with Rails, besides the technique I’m using which is illustrated in this git repository: https://github.com/justin808/react-webpack-rails-tutorial
Before discussing which technique for Webpack, there’s a few simple reasons I love it with Rails:
- Easily enables ES6 and JSX (ReactJs)
- Webpack Dev Server for Hot Module Replacement.
Let’s compare and contrast these techniques. What are the advantages? Disadvantages? Why did you pick one of them?
Justin Gordon: Webpack Stand Alone with Rails
Updated example: https://github.com/justin808/react-webpack-rails-tutorial
- I like how everything is 100% transparent.
- The sample project shows this working and even deploys to Heroku.
- It’s a bit of work getting this setup, but the example should make this pretty easy.
- By being transparent, there might be a bunch to get your head around.
Kevin Old: Webpack’s Dev Server for Rails Assets
This technique is based on the examples I generated. However it differs with the way that the development mode of Rails gets some assets from the Webpack dev server, which is running side by side. It seems that the hot reload may work inside of Rails, which would be quite exciting. I haven’t tried, so I can’t say.
I opened a github issue to try to incorporate some of these ideas in the example:
Dan Ott: webpack_rails Gem
webpack_rails is built to be used beside sprockets-rails, or in place of sprockets-rails, but not within sprockets-rails.
If it’s helpful, it can be thought of this way - we’re trying to build an alternative asset pipeline, that lives at /webpack instead of /assets. This avoids running into unexpected behavior, while providing clear division of labor between the tools.
I’m hoping that Dan might be able to comment here. Part of what I like about my transparent technique is just that it’s transparent. I have no fears that with upgrades to Rails that the simple technique will break.
Then again, a gem that does the magic might be appealing for some.