preface

For starters, webPack configuration items are many and heavy, and it is worth thinking about how to quickly configure a Webpack for use in an online environment. In fact, after you are familiar with WebPack, you will find that it is very simple. The basic configuration can be divided into the following aspects: Entry, Output, mode, resolve, Module, Optimization, Plugin, source map, performance, etc., this article will focus on these parts.

Enclosed is a webpack zero configuration comparison picture, follow the public number [front bottle] reply [webpack] free PDF file.

1. Configure entry

1. Single entrance and multiple entrances

Adding source files to the WebPack build process can be a single entry:

module.exports = {
  entry: `./index.js`,}Copy the code

Build package name [name] is main;

Or multiple entrances:

module.exports = {
  entry: { 
    "index": `./index.js`,}}Copy the code

Key :value The form of a key value pair:

  • Key: the name of the build package, i.e[name], where isindex
  • Value: indicates the entry path

The entry determines which module webAPck starts to generate the dependency diagram (build package), and each entry file corresponds to a dependency diagram.

2. Dynamic configuration entry file

Dynamically package all subprojects

When a build project contains multiple sub-projects, adding a subsystem requires writing the entry file to the WebPack configuration file. Instead, let WebPack dynamically retrieve the entry file. For example:

// Use a tool such as glob to get the entry entry at runtime using several wildcards
module.exports = {
  entry: glob.sync('./project/**/index.js').reduce((acc, path) = > {
    const entry = path.replace('/index.js'.' ')
    acc[entry] = path
    return acc
  }, {}),
}
Copy the code

All files that match./project/**/index.js are packaged as entry files. If you want to add a subproject, simply create a subproject directory in project and create an index.js entry file.

This approach is more suitable for the entry file is not centralized and more scenarios.

Dynamically package a subproject

When building a multi-system application or component library, we may only need to package one module at a time. In this case, we can request to print a module through the command line, for example:

npm run build --project components
Copy the code

Parse the command-line arguments while packaging:

// Parse the command-line arguments
const argv = require('minimist')(process.argv.slice(2))
/ / project
const project = argv['project'] | |'index'
Copy the code

Then configure the entry:

module.exports = {
  entry: { 
    "index": `. /${project}/index.js`,}}Copy the code

Is equivalent to:

module.exports = {
  entry: { 
    "index": `./components/index.js`,}}Copy the code

Of course, you can pass in other parameters, and it can be applied in multiple places, such as resolvie.alias.

2. Configure export output

To tell WebPack how to build the compiled file, you can customize the location and name of the output file:

module.exports = {
  output: { 
    // Path must be an absolute path
    // Output file path
    path: path.resolve(__dirname, '.. /.. /dist/build'),
    / / package name
    filename: "[name].bundle.js".// Or use a function to return the name (not often)
    // filename: (chunkData) => {
    // return chunkData.chunk.name === 'main' ? '[name].js': '[name]/[name].js';
    // },
    // Block name, common block name (not entry)
    chunkFilename: '[name].[chunkhash].bundle.js'.// Package the prefix of the resource referenced in the generated index.html file
    // Also for the URL prefix published to online resources
    // Use a relative path, default is ''
    publicPath: '/',}}Copy the code

In WebPack4 development mode, output. pathInfo is started by default, and it outputs some additional comment information, which is very useful for project debugging, especially when using the Eval DevTool.

Filename: specifies the key configured for the entry by [name]. In addition, the key can be [id] (internal block ID), [hash], and [Contenthash].

1. Browser cache and hash value

For every application we develop, the browser caches the static resource. If we update the static resource without updating the static resource name (or path), the browser may not get the updated resource due to caching problems. When we use WebPack for packaging, WebPack provides the concept of hash, so we can use hash for packaging.

When defining package names (e.g. ChunkFilename, filename), we usually use hash values. Different hash values are used in different scenarios:

hash

Build-specific: the hash value is different from each Compilation, even if the contents of the file have not changed and all resources share the same hash value. In this case, the browser cache is useless and can be used in development environments, not production environments.

chunkhash

Chunk-specific, the hash corresponds to each webPack entry point, and each entry has its own hash. If the content of a file changes on the dependency graph created by an entry file, then the chunkhash of the corresponding entry file changes and is applicable to the production environment

contenthash

Content-specific, a hash calculated based on the package contents, contenthash remains unchanged as long as the package contents remain unchanged, and is applicable to production environments

Webpack also allows hashing of slices. If you write [hash:8], it gets the first eight bits of the hash.

Note:
  • Try to use hashes in a production environment
  • Blocks loaded on demand are not affectedfilenameImpact,chunkFilenameimpact
  • usehash/chunkhash/contenthashWould normally cooperatehtml-webpack-plugin(Create HTML and bundle the corresponding package),clean-webpack-plugin(clean up the original package files).

2. Pack it as a library

When using Webapck to build a library that can be referenced by other modules:

module.exports = {
  output: { 
    // Path must be an absolute path
    // Output file path
    path: path.resolve(__dirname, '.. /.. /dist/build'),
    / / package name
    filename: "[name].bundle.js".// Block name, common block name (not entry)
    chunkFilename: '[name].[chunkhash].bundle.js'.// Package the prefix of the resource referenced in the generated index.html file
    // Also for the URL prefix published to online resources
    // Use a relative path, default is ''
    publicPath: '/'.// Once set, the bundle will be processed into a library
    library: 'webpackNumbers'.Specification / / the export of the library, and we have support var, this, commonjs, commonjs2, amd, umd
    libraryTarget: 'umd',}}Copy the code

3. Configuration mode mode (webpack4)

By setting mode, WebPack automatically adjusts the built-in optimizations accordingly.

module.exports = {
  // Can be none, development, production
  // Defaults to production
  mode: 'production'
}
Copy the code

Or on the command line:

"build:prod": "webpack --config config/webpack.prod.config.js --mode production"
Copy the code

After mode is set, WebPack4 synchronously configures process.env.NODE_ENV to either development or production.

Webpack4’s most notable features are:

  • Reduce compile time

    Packing time is reduced by more than 60%

  • Zero configuration

    We can use WebPack for various projects without any configuration files

Webpack4 supports zero configuration. In this case, mode and entry (SRC /index.js by default) can be specified in the entry file. Webpack4 has built-in optimization policies for different modes.

1. production

Configuration:

// webpack.prod.config.js
module.exports = {
  mode: 'production',}Copy the code

Built-in by default:

// webpack.prod.config.js
module.exports = {
  performance: {
    // Performance Settings, the file package is too large, the warning
    hints: 'warning'
  },
  output: {
    // When packaging, a comment that does not contain information about the owning module in the package
    pathinfo: false
  },
  optimization: {
    // Debug without a readable module identifier
    namedModules: false.// Debug without a readable block identifier
    namedChunks: false.// Set process.env.node_env to production
    nodeEnv: 'production'.// Mark whether the block is a subset of other blocks
    // Control the size of the load block (when the larger block is loaded, no subset is loaded)
    flagIncludedChunks: true.// Mark the loading sequence of modules so that the initial package is smaller
    occurrenceOrder: true.// Enable side effects
    sideEffects: true.// Determine the use export for each module,
    // No exports are generated for unused exports
    // Eliminate dead code to a minimum
    // optimization.usedExports Collects information that will be used by other optimizations or code generation
    usedExports: true.// Find the fragments of the module diagram that can be safely connected to other modules
    concatenateModules: true.// SplitChunksPlugin Configuration item
    splitChunks: {
      // By default webPack4 will only split code that is loaded on demand
      chunks: 'async'.// indicates the minimum module size before compression. The default is 30KB
      minSize: 30000.minRemainingSize: 0.// Intended for use with HTTP/2 and long-term caching
      // It increases the number of requests for better caching
      // It can also be used to reduce file size to speed up rebuilding.
      maxSize: 0.// The minimum number of blocks that must be shared before splitting a module
      minChunks: 1.// Maximum number of concurrent requests when loading on demand
      maxAsyncRequests: 6.// Maximum number of parallel requests for entry
      maxInitialRequests: 4./ / qualifier
      automaticNameDelimiter: '~'.// The maximum number of characters in the block name
      automaticNameMaxLength: 30.cacheGroups: { / / cache group
        vendors: {
          test: /[\\/]node_modules[\\/]/.priority: - 10
        },
        default: {
          minChunks: 2.priority: - 20.reuseExistingChunk: true}}},// When packing, an error compilation occurs, and the package file will not be exported
    // Make sure webPack doesn't enter any wrong packages
    noEmitOnErrors: true.checkWasmTypes: true./ / using optimization minimizer | | TerserPlugin to minimize the package
    minimize: true,},plugins: [
    // Use terser to optimize JavaScript
    new TerserPlugin(/ *... * /),
    // Define environment variables
    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production")}),// Precompile all modules into a closure to speed up code execution in the browser
    new webpack.optimize.ModuleConcatenationPlugin(),
    // Use NoEmitOnErrorsPlugin to skip the output phase when an error occurs during compilation.
    // This ensures that output resources do not contain errors
    new webpack.NoEmitOnErrorsPlugin()
  ]
}
Copy the code

2. development

Configuration:

// webpack.dev.config.js
module.exports = {
  mode: 'development',}Copy the code

Built-in by default:

// webpack.dev.config.js
module.exports = {
  devtool: 'eval'.cache: true.performance: {
    // Performance Settings: no error or warning is reported when the file package is too large
    hints: false
  },
  output: {
    // When packaging, include comments in the package for information about the owning module
    pathinfo: true
  },
  optimization: {
    // Debug with a readable module identifier
    namedModules: true.// Use readable block identifiers for debugging
    namedChunks: true.// Set process.env.node_env to development
    nodeEnv: 'development'.// Do not mark whether the block is a subset of other blocks
    flagIncludedChunks: false.// Do not mark the loading order of modules
    occurrenceOrder: false.// Disable side effects
    sideEffects: false.usedExports: false.concatenateModules: false.splitChunks: {
      hidePathInfo: false.minSize: 10000.maxAsyncRequests: Infinity.maxInitialRequests: Infinity,},// Output the package file when an error is encountered
    noEmitOnErrors: false.checkWasmTypes: false./ / don't use optimization. Minimizer | | TerserPlugin to minimize package
    minimize: false.removeAvailableModules: false
  },
  plugins: [
    // When HMR is enabled, using this plug-in displays the relative path of the module
    // Recommended for development environments
    new webpack.NamedModulesPlugin(),
    // WebPack internally maintains an incrementing ID, one for each chunk.
    // So when you add an entry or another chunk, the ID changes.
    // The id of the chunk whose content is unchanged has also changed
    // NamedChunksPlugin maps the internal chunk ID to a string identifier (the relative path of the module)
    // This makes the chunk ID stable
    new webpack.NamedChunksPlugin(),
    // Define environment variables
    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development")})]}Copy the code

3. none

There are no default tuning options.

Configuration:

// webpack.com.config.js
module.exports = {
  mode: 'none',}Copy the code

Built-in by default:

// webpack.com.config.js
module.exports = {
  performance: {
   // Performance Settings: no error or warning is reported when the file package is too large
   hints: false
  },
  optimization: {
    // Do not mark whether the block is a subset of other blocks
    flagIncludedChunks: false.// Do not mark the loading order of modules
    occurrenceOrder: false.// Disable side effects
    sideEffects: false.usedExports: false.concatenateModules: false.splitChunks: {
      hidePathInfo: false.minSize: 10000.maxAsyncRequests: Infinity.maxInitialRequests: Infinity,},// Output the package file when an error is encountered
    noEmitOnErrors: false.checkWasmTypes: false./ / don't use optimization. Minimizer | | TerserPlugin to minimize package
    minimize: false,},plugins: []}Copy the code

4. production, development, none

Production mode gives you a better user experience:

  • Smaller output packet volume
  • Faster code execution in the browser
  • Ignore code in development
  • Do not disclose source code or file paths
  • Easy to use output assets

The Development mode gives you the best development experience:

  • Browser debugging tool
  • Rapid incremental compilation speeds up the development cycle
  • The runtime provides useful error messages

Although WebPack4 is trying to do more with zero configuration, there is still a limit, and in most cases you will need a configuration file. We can use zero configuration at the beginning of the project and then configure it later when the business is complex.

5. Environment variable process.env.node_env

Third party frameworks or libraries, as well as our business code, will execute different logical code for different environment configurations, such as:

We can define environment variables in the following ways:

Process.env. NODE_ENV = ‘production’ by default, so webapck4 can not define mode: ‘production’

Although mode is defined in WebPack4 to automatically configure process.env.node_env, don’t we need to manually configure environment variables?

In fact, mode can only be defined as development or production. In a project, we not only have development or production environments, but also need to configure different environments (such as test environment). In this case, we need to manually configure other environment variables (such as test environment, Process.env.node_env is defined as ‘test’), which you can do in the following ways:

Method 2: Webpack.definePlugin

// Set the global variable process.env during webPack compilation
new webpack.DefinePlugin({
  'process.env': require('.. /config/dev.env.js')}Copy the code

The config/prod env. Js:

module.exports ={
  // or '"production", the value of the environment variable needs to be a string wrapped in double quotes
  NODE_ENV: JSON.stringify('production')}Copy the code

Method 3: NODE_ENV=development when running the webpack command

Setting NODE_ENV=production in window may get stuck, so use cross-env:

cross-env NODE_ENV=production webpack --config webpack.config.prod.js
Copy the code

Method four: usenew webpack.EnvironmentPlugin(['NODE_ENV'])

EnvironmentPlugin is a shortcut to set the process.env environment variable via webpack.definePlugin.

new webpack.EnvironmentPlugin({
  NODE_ENV: 'production'});Copy the code

Note: NODE_ENV is set to a default value of ‘production’. If process.env.node_env is defined elsewhere, this default value is invalid.

Configure the resolve policy

Custom policy for finding dependent modules (e.g. Import_ from ‘lodash’) :

module.exports = {
  resolve: {
    // Set module import rules, import/require will directly find files in these directories
    // You can specify the absolute path to third-party modules to reduce searching.
    / / node_modules by default
    modules: [path.resolve(`${project}/components`), 'node_modules'].// import Omit the suffix when importing
    // Note: minimize the possibility of suffix attempts
    extensions: ['.js'.'.jsx'.'.react.js'.'.css'.'.json'].// import alias to reduce time-consuming recursive resolution operations
    alias: {
      '@components': path.resolve(`${project}/components`),
      '@style': path.resolve('asset/style'),},Many third-party libraries provide several copies of code for different environments
    // WebPack will decide which code to use first based on the configuration of mainFields
    // The default value will vary depending on the target specified in the WebPack configuration
    mainFields: ['browser'.'module'.'main',}}Copy the code

Configure a policy module for parsing and converting files

To determine how to handle the different types of modules in a project, this is usually done by configuring the Loader in module.rules:

module.exports = {
  module: {
    // Specify that WebPack does not parse certain content, which can help improve WebPack build performance
    noParse: /jquery/.rules: [{// Compile js and JSX
        // Note: Do not write /\.jsx? If there is no JSX file in the project source code $/ to improve regular expression performance
        test: /\.(js|jsx)$/.// Specify what loader to use and its associated loader configuration
        use: {
          loader: "babel-loader".options: {
            // Babel-Loader supports caching of translated results, enabled with the cacheDirectory option
            // Use the cacheDirectory option to double the speed of Babel-Loader
      		cacheDirectory: true.// Save disk space when time isn't as important
      		cacheCompression: true.compact: true,}},// Exclude files in node_modules
        // The files in node_modules are in ES5 syntax, so there is no need to convert them through Babel
        exclude: /node_modules/
        // You can also configure include to include files that you want to import}}}]Copy the code

1. noParse

Indicates that WebPack does not parse certain content, which can help improve WebPack build performance.

2. rules

Common loaders are:

  • Babel-loader: parses.js and.jsx files

    / / configuration. Babelrc
    {
      "presets": [["@babel/preset-env",]."@babel/preset-react"]."plugins": [["@babel/plugin-proposal-class-properties",
          {
            "loose": true}], ["@babel/plugin-transform-runtime",
          {
            "absoluteRuntime": false."corejs": false."helpers": true."regenerator": true."useESModules": false}}]]Copy the code
  • Tsx-loader: processes TS files

  • Less-loader: processes less files and compiles them into CSS

  • Sass-loader: processes sASS and SCSS files and compiles them into CSS

  • Postcss – loader:

    // postcss.config.js
    module.exports = { // Parses the CSS file and adds the browser prefix to the CSS content
    	plugins: [require('autoprefixer')]};Copy the code
  • Css-loader: processes CSS files

  • Style-loader: injects CSS into the DOM

  • File-loader: parses the import/require file into a URL and outputs the file to an output directory

  • Url-loader: A WebPack loader used to convert files to Base64 URIs

  • Html-loader: Exports HTML as a string and minimizes HTML when required by the compiler

For more loaders, see loaders.

6. Configuration Optimization Optimization (WebPack4)

Webapck4 will optimize according to the mode you select, you can manually configure it, it will override the automatic Optimization, see Optimization for details.

The optimization mainly involves two aspects:

  • To minimize the package
  • unpacking

1. Minimize packages

  • useoptimization.removeAvailableModulesAn available module is deleted
  • useoptimization.removeEmptyChunksDeleting an empty module
  • useoptimization.occurrenceOrderMark the load order of modules so that the initial package is smaller
  • useoptimization.providedExportsoptimization.usedExportsconcatenateModulesoptimization.sideEffectsDeleting dead code
  • useoptimization.splitChunksExtracting common packages
  • useoptimization.minimizer || TerserPluginTo minimize packages

2. Unpacking

When the package is too large, if we update a small part of the package, then the entire package needs to be reloaded. If we split the package, then we only need to reload the changed package, not all packages, effectively using the cache.

Split node_modules

In many cases, we do not need to manually unbundle chunks. We can use optimizations. SplitChunks:

const path = require('path');
module.exports = {
  entry: path.resolve(__dirname, 'src/index.js'),
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',},optimization: {
    splitChunks: {
      // Split all packages
      chunks: 'all',}}};Copy the code

Instead of having a unpacking strategy, chunks: all will automatically put everything from node_modules into a file named Vendors ~ main.js.

Split business code
module.exports = {
  entry: {
    main: path.resolve(__dirname, 'src/index.js'),
    ProductList: path.resolve(__dirname, 'src/ProductList/ProductList.js'),
    ProductPage: path.resolve(__dirname, 'src/ProductPage/ProductPage.js'),
    Icon: path.resolve(__dirname, 'src/Icon/Icon.js'),},output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash:8].js',}};Copy the code

Adopt multi-entry way, when there is business code update, the corresponding package can be updated

Splitting third-party libraries
const path = require('path');
const webpack = require('webpack');

module.exports = {
  entry: path.resolve(__dirname, 'src/index.js'),
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].[contenthash].js',},optimization: {
    runtimeChunk: 'single'.splitChunks: {
      chunks: 'all'.maxInitialRequests: Infinity.minSize: 0.cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name(module) {
            // Obtain the third-party package name
            const packageName = module.context.match(/[\\/]node_modules[\\/](.*?) (/ / \ \ | $) /) [1];

            // NPM package names are URL-safe, but some servers do not like the @ symbol
            return `npm.${packageName.replace(The '@'.' ')}`; },},},},},},};Copy the code

When a third-party package is updated, only the corresponding package is updated.

Note that when there are too many packages, the browser will make more requests, and when the file is too small, it will have an impact on code compression.

Dynamic loading

So far we have split the package completely, but this is just an optimization of the browser cache to reduce the first screen load time. In fact, we can split the package further by using the on-demand loading method to reduce the first screen load time:

import React, { useState, useEffect } from 'react';
import './index.scss'

function Main() {
  const [NeighborPage, setNeighborPage] = useState(null)

  useEffect((a)= > {
    import('.. /neighbor').then(({ default: component }) = > {
      setNeighborPage(React.createElement(component))
    });
  }, [])

  return NeighborPage
    ? NeighborPage
    : <div>Loading...</div>;
}

export default Main
Copy the code

7. Configure plugin

Configure the Plugin to handle and optimize other requirements,

module.exports = {
  plugins: [
    / / optimize the require
    new webpack.ContextReplacementPlugin(/moment[\/\\]locale$/, /en|zh/),
    // To speed up the build
    createHappyPlugin('happy-babel'[{loader: 'babel-loader'.options: {
        presets: ['@babel/preset-env'."@babel/preset-react"].plugins: [['@babel/plugin-proposal-class-properties', {
            loose: true}]],// Babel-Loader supports caching of translated results, enabled with the cacheDirectory option
        cacheDirectory: true.// Save disk space when time isn't as important
        cacheCompression: true.compact: true,}}])]}Copy the code

Commonly used plugins:

  • html-webpack-plugin: Generates an HTML file and adds the package to the HTML
  • webpack-parallel-uglify-pluginCompress JS (multi-process parallel processing compression)
  • happypack: Multithreaded loader used to speed up the build process
  • hard-source-webpack-plugin: Provides intermediate caching steps for modules to significantly improve packaging speed
  • webpack-merge: Merges webpack configurations
  • mini-css-extract-pluginAbstract: the CSS
  • optimize-css-assets-webpack-pluginCompression CSS:
  • add-asset-html-webpack-plugin: Adds JavaScript or CSS assets to the HTML generated by the HTml-Webpack-plugin

More plugins available: Plugins

Configure devTool: source map

Configure how WebPack generates Source maps to enhance the debugging process. Different values significantly affect the speed of build and rebuild:

Production environment: The default value is NULL and is not set (None) or nosource-source-map

Development environment: Eval is the default value. Generally, eval, cheap-eval-source-map, and cheap-modol-eval-source-map are used

Strategy for:

  • Using cheap mode can greatly improve the efficiency of Souremap generation. There is no column information (it maps to the transformed code, not to the original code), we generally don’t care about column information in debugging, and some browser engines (such as V8) will give out column information even if the Source Map doesn’t have columns.
  • ** Continuous build efficiency can be greatly improved by using eval. ** Check the speed comparison table in the official documentation to see how fast eval is compiled.
  • Use Modules to support precompiled tools such as Babel (used as a loader in WebPack).

If the default Webpack Minimizer has been redefined (such as terser-webpack-plugin), you must provide the sourceMap: True option to enable Source Map support.

More information can be found at devtool

Configure performance

Performance controls how WebPack is notified when packaging is occurring beyond certain file limits for assets and entry points:

module.exports = {
  // Configure how to display performance prompts
  performance: {
    // Optional: warning, Error, false
    // false: if the file package is too large, no error or warning will be reported
    // Warning: displays a warning. Recommended for development environments
    // Error: display error, recommended to use in production environment, to prevent the deployment of too large production package, which may affect the performance of the page
    hints: false}}Copy the code

X. Configure others

1. Watch and watchOptions

watch

Monitor file updates and recompile when files are updated:

module.export = {
  // Enable the listening mode
  watch: true,}Copy the code

In Webpack-dev-server and Webpack-dev-Middleware, monitor mode is enabled by default.

Or we can start the listener (–watch) from the command line:

webpack --watch --config webpack.config.dev.js
Copy the code
watchOptions
module.export = {
  watch: true.// Customize the monitoring mode
  watchOptions: {
    // Exclude listening
    ignored: /node_modules/.// Wait 300ms (default) to execute the action after listening for the change.
    // Prevent files from being updated too quickly and recompiling too often
    aggregateTimeout: 300.// Check whether a file has changed by asking the system whether the specified file has changed
    // the default is 1000ms
    poll: 1000}}Copy the code

2. externals

For example, if you use jquery in your project and you introduce it in your HTML, you don’t need to include it in the package:

<script
  src="https://code.jquery.com/jquery-3.1.0.js"
  integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
  crossorigin="anonymous">
</script>
Copy the code

Configuration:

module.exports = {
  // Exclude jquery module when packaging
  externals: {
    jquery: 'jQuery'}};Copy the code

3.target

Build target to specify an environment for WebPack:

module.exports = {
  // Compile to a browser-like environment (default)
  target: 'web'
};
Copy the code

4. cache

Cache generated WebPack modules and blocks to increase build speed. Cache is set to type: ‘memory’ in development mode and disabled in production mode. Cache: true is an alias for cache: {type: ‘memory’}. To disable cache passing false:

module.exports = {
  cache: false
}
Copy the code

In memory, caching is only useful in monitor mode, and we assume that you use monitor mode in your development. Without caching, the memory footprint is small.

5. name

The name of the configuration used to load multiple configurations:

module.exports = {
  name: 'admin-app'
};
Copy the code

Xi. Summary

This article is just a list of common configuration items. All the configuration file architecture is visible: webPackoptions. json, you can also visit webPack website to learn more.

Previous webPack series

Five visual solutions to analyze WebPack performance bottlenecks

How it works: Hand write a JavaScript wrapper

For more on this series,Go to the Github blog home page

Reference:

webpack

The 100% correct way to split your chunks with Webpack

webpack 4: mode and optimization

Walk last

  1. ❤️ Have fun, keep learning, and always keep coding. 👨 💻

  2. If you have any questions or more unique opinions, please comment or directly contact The Bottle gentleman (the public number replies to 123)! 👀 👇

  3. 👇 welcome to pay attention to: front bottle gentleman, updated daily! 👇