My Best webpack Configuration To Date: Part 1

As part of the mythical journey towards the best webpack configuration, we add support for React and ESLint.

The fact that webpack is complicated is more about the complexity of the problem than any failings of webpack itself; a well constructed build process is a work of art providing both a highly optimized production build and at the same time a rapid development build environment.

While it is true that this series articles does end up providing a fully functional webpack configuration, the primary purpose is to explain it in detail. In this regard, this article heavily builds off of earlier articles that I have wr0itten on webpack:

webpack By Example: Part 1

webpack: Unraveling CommonsChunkPlugin

The examples in this and the earlier webpack articles are available for download.

react

While React is not a requirement of using webpack, webpack is the build tool of choice for React. As such, we will add React support to our webpack configuration.

Starting from the last example in the articles, v3-update, we:

yarn add babel-preset-react --dev
yarn add react
yarn add react-dom

We then update webpack.config.js to add React support.

./react/webpack.config.js

...
module.exports = function(env) {
  return ({
    resolve: {
      extensions: ['.js', '.jsx'],
    },
    devtool: env.NODE_ENV === 'production' ? 'source-map' : 'cheap-eval-source-map',
    entry: './src/index.jsx',
    output: {
      filename: env.NODE_ENV === 'production' ? '[name].[chunkhash].bundle.js' : '[name].bundle.js',
      path: path.resolve(__dirname, 'build')
    },
    module: {
      rules: [
        {
          test: /\.(js|jsx)$/,
          exclude: /node_modules/,
          loader: 'babel-loader',
        },
        {
          test: /\.(scss|css)$/,
...
new CleanWebpackPlugin(['build']),

We actually pulled out the babel configuration to a separate .babelrc file; the pattern is to use the tool specific configuration rather than passing it through a loader.

We also changed up the build folder; from dist to build. This change was made as the popular create-react-app application using this naming.

./react/.babelrc

{
  "presets": ["es2015", "react"],
  "plugins": [
    "syntax-dynamic-import"
  ]
}

note: Outside changing the extension of the entry point, adding React support does not prevent this webpack configuration for working with plain JavaScript.

We now change our application to use React; but we will hold off on dynamic imports for now. The updated application.

note: Also, I observed that we did not need to wrap the body CSS with global as we did in an earlier example; element selectors are not impacted by CSS modules.

eslint

I have come to a point, were I find it hard to code without a code syntax and style checker, linter, working behind the scenes. With React, one of the more popular solutions is eslint-config-airbnb. To install:

yarn add eslint-config-airbnb --dev
yarn add eslint --dev
yarn add eslint-plugin-import --dev
yarn add eslint-plugin-jsx-a11y --dev
yarn add eslint-plugin-react --dev

Configure eslint:

./eslint/.eslintrc

{
  "env": {
    "browser": true
  },
  "extends": [
    "airbnb"
  ]
}

To run eslint:

./node_modules/.bin/eslint src/ --ext .jsx

note: Interestingly enough, when I ran this command using the source code from the last, react, example, I got many styling errors. Again reminds me that I need to always have my linter running.

Most editors, including Atom, have support for eslint (likely through a plugin). With this, you can detect errors as you code.

In order to automate the checking during the build process, you can install a webpack loader.

yarn add eslint-loader --dev

And then add the following to webpack.config.js.

./eslint/webpack.config.js

...
module: {
    rules: [
      {
        enforce: 'pre',
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        loader: 'eslint-loader',
        options: {
          failOnWarning: true,
          failOnError: true,
        },
      },
      {
        test: /\.(js|jsx)$/,
...

note: One I installed the linting configuration, I also had to fix a number of minor styling issues, .e.g., missing commas, etc, in the webpack.config.js file itself.

With this configuration in place, webpack will not successfully compile when there are linting errors. This is particularly nice if you are using some sort of continuous integration solution and want to automatically validate the code before it is deployed.

note: On a related note, there is no need to run the bundle analyzer on each build; especially if you are using a continuous integration solution. Went ahead and commented it out until I need it again.

Next Steps

Funny, I thought this was going to be a single article (especially having referenced nine earlier articles on webpack). But no, there is more; My Best webpack Configuration To Date: Part 2.