React on Rails with rails/webpacker 4.x

[justin808]

Problem

With the 4.2.2 version of Webpacker (and maybe some earlier versions), webpacker will run a "cleanup" task after compilation.

The goal for this cleanup is the same as older Sprockets. Assets older than a couple of versions get deleted. The problem is when we're building an unversioned, no-hash-in-name, server bundle inside the same output directory. Since rails/webpacker does know about the files outside of the manifest, it just deletes them.

Here is one of the PRs that resulted in this cleanup behavior: rails/webpacker#2389.

So, what's the cleanest way to have custom webpack configuration build a server bundle without risking conflicts with rails/webpacker for the long-term?

Options

1. Move the server bundle so it’s not within or in a subdirectory of the client files. This can be done with a file specification like this, in config/initializers/react_on_rails.rb:

  config.server_bundle_js_file = "../#{Rails.env}-server/server-bundle.js"

The output file should be configured like

const serverBundleOutput = () => ({
  filename: `../${railsEnv}-server/server-bundle.js`,
  path: config.outputPath,
  publicPath: config.outputPath,
});

2. Have the server-bundle hashed and included in the manifest. Normally, there is little advantage to having a hash on the server bundle. It gets rebuilt at each deployment. Since browsers do not read this file, there's no necessity to have this file fingerprinted. However, if this file is not hashed and in the same directory as the other webpack client files, then rails/webpacker doesn't know to keep it. Webpack plugin webpack-assets-manifest has an option for "merge". The plugin option merge should be set to true. One disadvantage of doing this is that concurrently building the client and server bundles is likely hazardous due to the possible concurrent modification of the manifest file. Thus, the flow should be run the client and server builds sequentially.

[justin808]

This change is no longer needed. See #1245.