Webpack

Yarn helps us manage our dependencies, and webpack is what allows us to refer to the dependencies in our code.

It’s a little tricky to talk about webpack in the context of our project because webpack’s behavior depends on its configuration file, and one of the things Rails Webpacker does is generate that configuration file from different inputs so we don’t actually see the real webpack configuration in a file.

There’s a partial workaround that will allow us to print out the configuration file, or at least most of it, and I’m going to use it to guide our way through the way webpack works, and then I’m going to talk about how Webpacker simplifies webpack.

The workaround to let us actually see our webpack configuration is to go to the file config/webpack/development.js and add the following lines at the end of the script:

Object.defineProperty(RegExp.prototype, "toJSON", {
  value: RegExp.prototype.toString
});

console.log(JSON.stringify(module.exports, null, 2))

At this point, module.exports is an object containing the webpack config as JSON, so we’re just asking to print it to the console with a two-space indent. We’re also adding a little bit of extra code so that the regular expressions print properly. This won’t get us the full text representation of the webpack config, but I think it’s as close as we can easily get.

With that code in place, if you run the command bin/webpack, you’ll see the entire webpack configuration in your terminal window.

I’m not going to show the entire thing here in one piece; I’m going to break it down to cover webpack’s main concepts. For each section, I’ll discuss the webpack syntax and what it means, and then I’ll discuss how Rails Webpacker uses defaults and convention to generate the configuration.

Mode

I’m going to show all these snippets one by one, but please remember that they are part of the larger configuration file. Also, these snippets may not exactly match the order that your file prints in.

{
  "mode": "development",
  "devtool": "cheap-module-source-map",
}

Unlike Rails, webpack only cares about two modes: development and production (okay, strictly speaking you can set the mode to none, but please don’t do that). This setting sets the NODE_ENV environment variable, and that value might be used within the code to manage features. Setting production is typically used to run some optimization plugins that we are not going to detail here.

In Rails, Webpacker sets this variable based on your Rails environment, if you are not in development, you are in production. So, for example, a staging environment gets the production plugins. But, just to be a little confusing, Webpacker allows you to maintain separate configuration files based on your Rails environment.

So, Webpacker allows you to generate, say, a different environment for testing, but the NODE_ENV environment variable in that configuration will still be set to either development or production by the Webpacker config.

The devtool parameter controls the generation of source maps. A source map is a separate file that relates lines in your originally coded file in TypeScript, CoffeeScript, or what have you with the JavaScript file eventually sent to the browser. With a source map, debugging tools in the browser can show you your original file ...