It’s been a while since WebPack 4 was released, although the official documentation and upgrade guide are not complete, and some plug-ins for WebPack 4 are still under development, but for a veteran front-end configuration engineer, the big Blade is already starving, so here is an unofficial UPGRADE (CAI) guide.

I don’t have time for this. Get me a configuration

Webpack 4 has made a lot of improvements, so I’ll just pick out a few that I care about

0CJS

With the popularity of zero-configuration, out-of-the-box packaging tools like Parcel, the pressure is clearly on webPack, which has been criticized for being difficult to use, understand, and configure. In version 4.0, it added default values for some configurations and introduced the concept of Mode, which provides two different default configurations for development and production environments. Greatly simplifies webPack configuration. In version 4.0, you don’t even need to configure it to use it (which is useless).

The default value

1

2

3

4

5

6

7

 
module.exports = {

  entry: 'src/',

  outpu: {

    filename: '[name].js',

    path: 'dist/'

  }

}

The mode introduced in Webpack 4 is mandatory (it will alert you if it’s not set), and you can use webpack –mode… Can also be set via webpack.config.js.

1

2

3

 
module.exports = {

  mode: 'development' // development || production

}

Mode is also used to simplify configuration items. Different modes set different default configurations for us, so we don’t need to configure them separately.

The development model focuses more on the development experience:

  • Better for browser debugging
  • Faster incremental compilation speed
  • More detailed error message

Generative mode is more about user experience:

  • Performance (file size, run performance, packaging speed)

Full instructions can be found in this article

The Loader and the Plugin

In fact, there is no change in loader. The loader I used can be directly used when upgraded to the latest version, and some even need not be upgraded. The big change is the plugin. Webpack 4 uses a new plugin system, so most of the previous plug-ins need to be changed, so how do they support WebPack 4 so far?

  • [email protected]

    As can be seen from the issue list, there are still many problems. The problem I personally ran into was generating a 0KB CSS file, issue, with splitChunks(to be covered later). I already mentioned PR for this question.

    There is an official mini-CSS-extract-plugin, but there are more problems. It does not support HMR and contenthash, so it is basically unusable at present.

  • [email protected] +

    This plugin currently supports WebPack 4, but not necessarily its own plugin, so be aware of this when upgrading

  • uglifyjs-webpack-plugin

    This plugin currently supports WebPack 4 as well. In production mode, code is compressed by default. Of course, if you have more detailed customization requirements, you can use this plug-in.

RIP CommonsChunkPlugin

The most significant changes are the CommonsChunkPlugin replacement with Optimization.splitchunks in WebPack 4 and the removal of the CommonsChunkPlugin. So this part is a bit of a hassle to migrate.

The CommonsChunkPlugin will be familiar to configuration engineers. We use it to extract common parts of code, such as WebPack Runtime, in combination with Chunkhash to achieve the best caching strategy. However, this part is also poorly supported by Webpack. The issue, which is almost three years old, has not been solved yet. If you are interested in this question, read this article. I won’t expand it here, but post a configuration from the CommonsChunkPlugin era to solve this problem

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

 
module.exports = {

.

  plugins: [

.

    new webpack.HashedModuleIdsPlugin(),



    new webpack.NamedChunksPlugin(chunk => {

      if (chunk.name) {

        return chunk.name

      } else {

        return 'faceless-chunk' // a chunk has no name

      }

    }),



    new webpack.optimize.CommonsChunkPlugin({

      name: 'vendor',

      minChunks (module) {

        return (

          module.resource &&

          /\.js$/.test(module.resource) &&

          /node_modules/.test(module.resource)

        )

      }

    }),



    // extract webpack runtime and module manifest to its own file in order to

    // prevent vendor hash from being updated whenever app bundle is updated

    new webpack.optimize.CommonsChunkPlugin({

      name: 'runtime',

      minChunks: Infinity

    }),



    // extracts shared chunks from code splitted chunks

    // https://github.com/webpack/webpack/issues/4392

    new webpack.optimize.CommonsChunkPlugin({

      name: 'app',

      async: 'async-vendor',

      children: true,

      minChunks: 3

    })



  ]

}

Configuration after upgrading to WebPack 4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

 
module.exports = {

.

  optimization: {

    splitChunks: {

      cacheGroups: {

        vendors: {

          test: /[\\/]node_modules[\\/]/,

          chunks: 'initial',

          name: 'vendors',

        },

        'async-vendors': {

          test: /[\\/]node_modules[\\/]/,

          minChunks: 2,

          chunks: 'async',

          name: 'async-vendors'

        }

      }

    },

    runtimeChunk: { name: 'runtime' }

  },

  plugins: [

    new webpack.HashedModuleIdsPlugin(),

    new webpack.NamedChunksPlugin(chunk => chunk.name || 'faceless-chunk'), // a chunk has no name!!!

.

  ]

}

You can see the full configuration here.

In fact, the migration time is quite long, on the one hand to raise the issue for Webpack, on the other hand to raise the issue and PR for wepback plugin. I was impressed by the time wepback took to fix the issue, but the plugin was slow to respond and it might take a few days to get feedback. All in all, I hope this article can help students who are upgrading or planning to upgrade.