Webpack 4 and the separation of the configuration file into modules

Hi, Habr! Today I will tell you about Webpack 4 with the division of code into separate modules, as well as interesting solutions that will help you to quickly assemble the assembly on the webpack 4. In the end, I will provide my basic assembly on the webpack with the most necessary tools that you can later to expand. This assembly will help you understand this material, and also possibly help you write your implementation faster and solve possible problems faster.

The main ideology of this assembly is the correct separation of code inside the configuration file for ease of use, reading and cleanliness of webpack.config.js. The required modules and plug-ins for the dev and prod versions (as well as for sharing functionality in the main file) will be located in a separate webpack folder and imported from it to connect to the main config.

Why do you need such an approach?

With the gradual increase in the number of modules, plug-ins, etc., that your build on the web pack grows with, the configuration file grows like a yeast. Over time, this file becomes difficult to read, and to change it for a specific project, if some modules in it are not used, it becomes more difficult, but you want something universal. Therefore, a clear code organization is required.

What do we need?

We will use the webpack-merge plugin .

Create a webpack folder and put all the individual modules into separate files. For example, webpack / pug.js, webpack / scss.js and export these functions from them.

Pug.js file

module.exports = function() {
  return {
    module: {
      rules: [
        {
          test: /\.pug$/,
          loader: 'pug-loader',
          options: {
            pretty: true,
          },
        },
      ],
    },
  };
};

The webpack.config.js file . In this file we connect them, and with the help of this plugin we connect them quickly and easily.

const merge = require('webpack-merge');
const pug = require('./webpack/pug');
const common = merge([
  {
    entry: {
      'index': PATHS.source + '/pages/index/index.js',
      'blog': PATHS.source + '/pages/blog/blog.js',
    },
    output: {
      path: PATHS.build,
      filename: './js/[name].js',
    },
    plugins: […],
    optimization: { … },
  },
  pug(),
]);

Now, if we have a new task, for which we need a new module, a plugin, a loader, then we take it to the hotel module (file) and put it in the webpack folder, and then connect it to the main configuration file, keeping the config as clean as possible.

Settings for production and development

Now, with the help of the banal if, we will finish our separation, which we aspire to, and configure our webpack for these two types of development, thanks to which it will finally become convenient to use this tool, and also in the future we will be able to flexibly and simply customize it for any other project, or expand in the current. For export to the node (for the webpack itself) in webpack 4 we use the following construction:

module.exports = function(env, argv) {
  if (argv.mode === 'production') {
    return merge([
      common,
      extractCSS(),
      favicon(),
    ]);
  }
  if (argv.mode === 'development') {
    return merge([
      common,
      devserver(),
      sass(),
      css(),
      sourceMap(),
    ]);
  }

In the common object, we connect what is used both in the prode and in development, and in the conditions we connect only those modules that are necessary in these cases.

Now I would like to talk about the main features of webpack 4 regarding webpack 3

• For a quick start, webpack 4 does not need webpack.config.js, it now only needs an entry point (index.js)
• In the new version of the webpack command line interface is placed in a separate package and you need to install webpack-cli.
• To start webpack 4, it is necessary (otherwise it will be warning) in the scripts to specify mode (mode of operation) --mode production or --mode development, depending on the key, the operation of the webpack changes. Development mode aims to speed up the build. In the production version, everything is directed to the final code minification.
• In order to create common.js and common.css files, the CommonsChunkPlugin is no longer used, splitChunks are now responsible for this and use the following construction:
  
  

      optimization: {
        splitChunks: {
          cacheGroups: {
            'common': {
              minChunks: 2,
              chunks: 'all',
              name: 'common',
              priority: 10,
              enforce: true,
            },
          },
        },
      },
  

  
  In webpack 3 - this would be the case in plugins:
  
  

  new webpack.optimize.CommonsChunkPlugin({ name: 'common ', })

  
  Accordingly, in the chunks in HtmlWebpackPlugin we connect (here without changes).
  
  

      
  plugins: [
        new HtmlWebpackPlugin({
          filename: 'index.html',
          chunks: ['index', 'common'],
          template: PATHS.source + '/pages/index/index.pug',
        }),
      ],
  

  
  
• The next important point, in order to create a sourceMap, now we use the following approach - we create the sourceMap.js file in the webpack folder and connect it in version devs for example (as mentioned above):
  
  

  module.exports = function() {
    return {
      devtool: 'eval-sourcemap',
    }; 
  };
  

Now the approach with plugins: [new webpack.optimize.UglifyJsPlugin ({})] does not work.

At this point, I would like to complete my story and provide my basic build - a link to webpack 4, which may help you in your work and development. Thanks for attention!