Influencing Webpacker Rather than Forking to Support Webpacker in React on Rails

react on railsJune 01, 2017Dotby Justin Gordon

This article provides some background discussion of my work to influence Webpacker and how that lead to the creation of Webpacker Lite, as described in Webpacker Lite: Why Fork Webpacker?

My initial goal, when I saw the work on Webpacker, was to nudge it in a direction that could support React on Rails.

Originally, Webpacker was configured to use standard Ruby on Rails configuration in a Ruby file in the /config/initializers directory. With Ruby files, the Javascript code would either have to get the values from environment values set in the Ruby “binstubs,” or the Javascript code would have to parse the Ruby configuration file. I introduced the idea of changing that configuration to YAML here and fleshed out the idea here.

YAML files would provide a configuration to both the Ruby on Rails view helpers and the JavaScript Webpack configs on how to to get the right asset file for use in any Rails/Node environment, including the configuration of hot-reloading for development. JavaScript likes reading YAML better than parsing Ruby!

I went further to influence the overall direction of Webpacker with Issue 139: Suggested Refinements on the Purpose and Scope of Webpacker.

Many of these ideas went into my work with Gaurav Tiwari on Webpacker PR 153: Add static assets support.

Upon merging of Webpacker PR 153, Daniel Szatmari and I went about creating React on Rails PR #811 Webpacker integration, which upgraded React on Rails to primarily supporting the Webpacker gem, and thus avoiding the “asset pipeline” when going from Webpack to deployed front-end assets (JavaScript, CSS, images, fonts, etc.).

During implementation, we ran into trouble and confusion, primarily due to the needs of Webpacker to configure the setup so that there was no custom Webpack configuration, which ran contrary to the React on Rails objective of being explicitly unopinionated regarding the configuration of the Webpack tooling.

I reported this problem in issue #238: The output directory in the config should be the output directory, per the image shown above regarding the paths.yml file. The big problem is the README comment “behind the scenes,” which is fine if webpacker is handling the webpack configuration, but not if you are.

Please note, that both Webpacker and Webpacker Lite evolved, so many of the issues discussed above have evolved. That being said, I’m super happy with my decision to provide a separate fork of Webpacker that best suits React on Rails users.

Closing Remark

Could your team use some help with topics like this and others covered by ShakaCode's blog and open source? We specialize in optimizing Rails applications, especially those with advanced JavaScript frontends, like React. We can also help you optimize your CI processes with lower costs and faster, more reliable tests. Scraping web data and lowering infrastructure costs are two other areas of specialization. Feel free to reach out to ShakaCode's CEO, Justin Gordon, at justin@shakacode.com or schedule an appointment to discuss how ShakaCode can help your project!
Are you looking for a software development partner who can
develop modern, high-performance web apps and sites?
See what we've doneArrow right