帮你学会webpack

webpack

本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

入口起点(entry points)

在 webpack 配置中有多种方式定义 entry 属性

单个入口（简写）语法

用法：entry: string|Array<string>

// webpack.config.js

const config = {
    
    
  entry: './src/index.js',
};

module.exports = config;

entry 属性的单个入口语法，是下面的简写：

const config = {
    
    
  entry: {
    
    
    main: './src/index.js',
  },
};

对象语法

用法：entry: {[entryChunkName: string]: string|Array<string>}

const config = {
    
    
  entry: {
    
    
    app: './src/app.js',
    vendors: './src/vendors.js',
  },
};

“可扩展的 webpack 配置”是指，可重用并且可以与其他配置组合使用。这是一种流行的技术，用于将关注点(concern)从环境(environment)、构建目标(build target)、运行时(runtime)中分离。然后使用专门的工具（如 webpack-merge）将它们合并。

常见场景

分离 应用程序(app) 和 第三方库(vendor) 入口

const config = {
    
    
  entry: {
    
    
    app: './src/app.js',
    vendors: './src/vendors.js',
  },
};

多页面应用程序

const config = {
    
    
  entry: {
    
    
    pageOne: './src/pageOne/index.js',
    pageTwo: './src/pageTwo/index.js',
    pageThree: './src/pageThree/index.js',
  },
};

输出(output)

配置 output 选项可以控制 webpack 如何向硬盘写入编译文件。注意，虽然可以存在多个入口起点，但只指定一个输出配置。

用法(Usage)

在 webpack 中配置 output 属性的最低要求是，将它的值设置为一个对象，包括以下两点：

• filename 用于输出文件的文件名。 -目标输出目
• path 的绝对路径。

webpack.config.js

const config = {
    
    
  output: {
    
    
    path: path.join(__dirname, 'dist'),
    filename: 'bundle.js',
  },
};

module.exports = config;

多个入口起点

如果配置创建了多个单独的 “chunk”（例如，使用多个入口起点或使用像 splitChuckPlugin —> webpack 4.0 后提供 这样的插件），则应该使用占位符(substitutions)来确保每个文件具有唯一的名称。

const config = {
    
    
  entry: {
    
    
    app: './src/app.js',
    search: './src/search.js',
  },
  output: {
    
    
    filename: '[name].js',
    path: __dirname + '/dist',
  },
};

// 写入到硬盘：./dist/app.js, ./dist/search.js

模式(mode)

提供mode配置选项，告知 webpack 使用相应模式的内置优化。

string

用法

只在配置中提供 mode 选项

module.exports = {
    
    
  mode: 'production',
};

或者从 CLI 参数中传递：

webpack --mode=production

选项	描述
development	会将 process.env.NODE_ENV 的值设为 development。启用 NamedChunksPlugin 和 NamedModulesPlugin。
production	将 process.env.NODE_ENV 的值设为 production。启用 FlagDependencyUsagePlugin, FlagIncludedChunksPlugin, ModuleConcatenationPlugin, NoEmitOnErrorsPlugin, OccurrenceOrderPlugin, SideEffectsFlagPlugin 和 UglifyJsPlugin.
none	会将 process.env.NODE_ENV 的值设为 none，不做任何处理

记住，只设置 NODE_ENV，则不会自动设置 mode。

loder

loader 用于对模块的源代码进行转换。loader 可以使你在 import 或"加载"模块时预处理文件。因此，loader 类似于其他构建工具中“任务(task)”，并提供了处理前端构建步骤的强大方法。loader 可以将文件从不同的语言（如 TypeScript）转换为 JavaScript，或将内联图像转换为 data URL。loader 甚至允许你直接在 JavaScript 模块中 import CSS 文件！

使用 loader

在你的应用程序中，有三种使用 loader 的方式：

• 配置（推荐）：在 webpack.config.js 文件中指定 loader。
• 内联：在每个 import 语句中显式指定 loader。
• CLI：在 shell 命令中指定它们。

配置[Configuration]

module.rules 允许你在 webpack 配置中指定多个 loader。 这是展示 loader 的一种简明方式，并且有助于使代码变得简洁。同时让你对各个 loader 有个全局概览：

const config = {
    
    
  module: {
    
    
    rules: [
      {
    
    
        test: /\.css$/,
        use: [
          {
    
     loader: 'style-loader' },
          {
    
    
            loader: 'css-loader',
            options: {
    
    
              modules: true,
            },
          },
        ],
      },
    ],
  },
};

内联

可以在 import 语句或任何等效于 “import” 的方式中指定 loader。使用 ! 将资源中的 loader 分开。分开的每个部分都相对于当前目录解析。

import Styles from 'style-loader!css-loader?modules!./styles.css';

通过前置所有规则及使用 !，可以对应覆盖到配置中的任意 loader。

选项可以传递查询参数，例如 ?key=value&foo=bar，或者一个 JSON 对象，例如 ?{“key”:“value”,“foo”:“bar”}。

尽可能使用 module.rules，因为这样可以减少源码中的代码量，并且可以在出错时，更快地调试和定位 loader 中的问题。

CLI

webpack --module-bind jade-loader --module-bind ‘css=style-loader!css-loader’
这会对 .jade 文件使用 jade-loader，对 .css 文件使用 style-loader 和 css-loader。

loader 特性

• loader 支持链式传递。能够对资源使用流水线(pipeline)。一组链式的 loader 将按照相反的顺序执行。
• loader 链中的第一个 loader 返回值给下一个 loader。在最后一个 loader，返回 webpack 所预期的 JavaScript。
• loader 可以是同步的，也可以是异步的。
• loader 运行在 Node.js 中，并且能够执行任何可能的操作。
• loader 接收查询参数。用于对 loader 传递配置。
• loader 也能够使用 options 对象进行配置。
• 除了使用 package.json 常见的 main 属性，还可以将普通的 npm 模块导出为 loader，做法是在 package.json 里定义一个 loader 字段。
• 插件(plugin)可以为 loader 带来更多特性。
• loader 能够产生额外的任意文件。

插件(plugins)

插件是 webpack 的支柱功能。webpack 自身也是构建于，你在 webpack 配置中用到的相同的插件系统之上！

插件目的在于解决 loader 无法实现的其他事。

剖析

webpack 插件是一个具有 apply 属性的 JavaScript 对象。apply 属性会被 webpack compiler 调用，并且 compiler 对象可在整个编译生命周期访问。

用法

由于插件可以携带参数/选项，你必须在 webpack 配置中，向 plugins 属性传入 new 实例。

根据你的 webpack 用法，这里有多种方式使用插件。

配置

const HtmlWebpackPlugin = require('html-webpack-plugin'); //通过 yarn或者npm 安装
const webpack = require('webpack'); //访问内置的插件
const path = require('path');

const config = {
    
    
  entry: './src/index.js',
  output: {
    
    
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    
    
    rules: [
      {
    
    
        test: /\.(js|jsx)$/,
        use: 'babel-loader',
      },
    ],
  },
  plugins: [
    new webpack.optimize.UglifyJsPlugin(),
    new HtmlWebpackPlugin({
    
     template: './src/index.html' }),
  ],
};

module.exports = config;

Node API

即便使用 Node API，用户也应该在配置中传入 plugins 属性。compiler.apply 并不是推荐的使用方式。

// some-node-script.js

const webpack = require('webpack'); //访问 webpack 运行时(runtime)
const configuration = require('./webpack.config.js');

let compiler = webpack(configuration);
compiler.apply(new webpack.ProgressPlugin());

compiler.run(function (err, stats) {
    
    
  // ...
});

以上看到的示例和webpack 自身运行时(runtime) 极其类似。webpack 源码 中隐藏有大量使用示例，你可以用在自己的配置和脚本中。

开发工具

在每次编译代码时，手动运行 npm run build 会显得很麻烦。

webpack 提供几种可选方式，帮助你在代码发生变化后自动编译代码：

• webpack watch mode(webpack 观察模式)
• webpack-dev-server
• webpack-dev-middleware
  大多数场景下我们会使用 webpack-dev-server

使用 watch mode(观察模式)

你可以指示 webpack “watch” 依赖图中所有文件的更改。如果其中一个文件被更新，代码将被重新编译，所以你不必再去手动运行整个构建。

启动 webpack watch mode

webpack --watch

如果能够自动刷新浏览器就更好了，因此可以通过 browser-sync 实现此功能。

缺点: 每次编译都要读写磁盘

使用 webpack-dev-server

webpack-dev-server 为你提供了一个简单的 web server，并且具有 live reloading(实时重新加载) 功能。

安装

npm i webpack-dev-server -D

// webpack.config.js

module.exports = {
    
    
  devServer: {
    
    
    // 当使用内联模式(inline mode)时，控制台(console)将显示消息，可能的值有 none, error, warning 或者 info（默认值）。
    clientLogLevel: 'none',
    //当使用 HTML5 History API 时，任意的 404 响应都可能需要被替代为 index.html
    historyApiFallback: {
    
    
      index: `index.html`,
    },
    // 启用 webpack 的模块热替换特性
    hot: true,
    // 告诉服务器从哪里提供内容。只有在你想要提供静态文件时才需要。我们这里直接禁用掉
    contentBase: false,
    // 一切服务都启用gzip 压缩：
    compress: true,
    // 指定使用一个 host。默认是 localhost
    host: 'localhost',
    // 指定要监听请求的端口号
    port: '8000',
    // local服务器自动打开浏览器。
    open: true,
    // 当出现编译器错误或警告时，在浏览器中显示全屏遮罩层。默认情况下禁用。
    overlay: false,
    // 浏览器中访问的相对路径
    publicPath: '',
    // 代理配置
    proxy: {
    
    
      '/api/': {
    
    
        target: 'https://github.com/',
        changeOrigin: true,
        logLevel: 'debug',
      },
    },
    // 除了初始启动信息之外的任何内容都不会被打印到控制台。这也意味着来自 webpack 的错误或警告在控制台不可见。
    // 我们配置 FriendlyErrorsPlugin 来显示错误信息到控制台
    quiet: true,
    // webpack 使用文件系统(file system)获取文件改动的通知。监视文件 https://webpack.js.org/configuration/dev-server/#devserver-watchoptions-
    watchOptions: {
    
    
      poll: false,
    },
    disableHostCheck: true,
  },
};

webpack-dev-server 具有许多可配置的选项。关于其他更多配置，请查看配置文档

使用 webpack-dev-middleware

Devtool

此选项控制是否生成，以及如何生成source map

使用 SourceMapDevToolPlugin 进行更细粒度的配置。查看 source-map-loader 来处理已有的 source map。

devtool

string false

选择一种 source map 格式来增强调试过程。不同的值会明显影响到构建(build)和重新构建(rebuild)的速度。

你可以直接使用 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 来替代使用 devtool 选项，因为它有更多的选项。切勿同时使用 devtool 选项和 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 插件。devtool 选项在内部添加过这些插件，所以你最终将应用两次插件。

git 仓库 里有用于测试 Source Map 示例，便于理解下面的 Source Map 对比表格

devtool	构建速度	重新构建速度	生产环境	质量(quality)
none	+++	+++	yes	打包后的代码
eval	+++	+++	no	生成后的代码
cheap-eval-source-map	+	++	no	转换过的代码（仅限行）
cheap-module-eval-source-map	o	++	no	原始源代码（仅限行）
eval-source-map	–	+	no	原始源代码
cheap-source-map	+	o	no	转换过的代码（仅限行）
cheap-module-source-map	o	-	no	原始源代码（仅限行）
inline-cheap-source-map	+	o	no	转换过的代码（仅限行）
inline-cheap-module-source-map	o	-	no	原始源代码（仅限行）
source-map	–	–	yes	原始源代码
inline-source-map	–	–	no	原始源代码
hidden-source-map	–	–	yes	原始源代码
nosources-source-map	–	–	yes	无源代码内容

+++ 非常快速, ++ 快速, + 比较快, o 中等, - 比较慢, – 慢

其中一些值适用于开发环境，一些适用于生产环境。对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在。

质量(quality)说明

• 打包后的代码

  将所有生成的代码视为一大块代码。你看不到相互分离的模块。

• 生成后的代码

  每个模块相互分离，并用模块名称进行注释。可以看到 webpack 生成的代码。示例：你会看到类似 var moduleWEBPACK_IMPORTED_MODULE_1 = webpack_require(42); moduleWEBPACK_IMPORTED_MODULE_1.a();，而不是 import {test} from “module”; test();。

• 转换过的代码

  每个模块相互分离，并用模块名称进行注释。可以看到 webpack 转换前、loader 转译后的代码。示例：你会看到类似 import {test} from “module”; var A = function(_test) { … }(test);，而不是 import {test} from “module”; class A extends test {}。

• 原始源代码

  每个模块相互分离，并用模块名称进行注释。你会看到转译之前的代码，正如编写它时。这取决于 loader 支持。

• 无源代码内容

  source map 中不包含源代码内容。浏览器通常会尝试从 web 服务器或文件系统加载源代码。你必须确保正确设置 output.devtoolModuleFilenameTemplate，以匹配源代码的 url。

• （仅限行）

  source map 被简化为每行一个映射。这通常意味着每个语句只有一个映射（假设你使用这种方式）。这会妨碍你在语句级别上调试执行，也会妨碍你在每行的一些列上设置断点。与压缩后的代码组合后，映射关系是不可能实现的，因为压缩工具通常只会输出一行。

对于开发环境

以下选项非常适合开发环境：

• eval

  每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会非常快地构建。主要缺点是，由于会映射到转换后的代码，而不是映射到原始代码（没有从 loader 中获取 source map），所以不能正确的显示行数。

• eval-source-map

  每个模块使用 eval() 执行，并且 source map 转换为 DataUrl 后添加到 eval() 中。初始化 source map 时比较慢，但是会在重新构建时提供比较快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。它会生成用于开发环境的最佳品质的 source map。

• cheap-eval-source-map

  类似 eval-source-map，每个模块使用 eval() 执行。这是 “cheap(阉割版)” 的 source map，因为它没有生成列映射(column mapping)，只是映射行数。它会忽略源自 loader 的 source map，并且仅显示转译后的代码，就像 eval devtool。

• cheap-module-eval-source-map

  类似 cheap-eval-source-map，并且，在这种情况下，源自 loader 的 source map 会得到更好的处理结果。然而，loader source map 会被简化为每行一个映射(mapping)。

特定场景

以下选项对于开发环境和生产环境并不理想。他们是一些特定场景下需要的，例如，针对一些第三方工具。

• inline-source-map

  source map 转换为 DataUrl 后添加到 bundle 中。

• cheap-source-map

  没有列映射(column mapping)的 source map，忽略 loader source map。

• inline-cheap-source-map

  类似 cheap-source-map，但是 source map 转换为 DataUrl 后添加到 bundle 中。

• cheap-module-source-map

  没有列映射(column mapping)的 source map，将 loader source map 简化为每行一个映射(mapping)。

• inline-cheap-module-source-map

  类似 cheap-module-source-map，但是 source map 转换为 DataUrl 添加到 bundle 中。

对于生产环境

这些选项通常用于生产环境中：

• none（省略 devtool 选项）

  不生成 source map。这是一个不错的选择。

• source-map

  整个 source map 作为一个单独的文件生成。它为 bundle 添加了一个引用注释，以便开发工具知道在哪里可以找到它。

你应该将你的服务器配置为，不允许普通用户访问 source map 文件！

• hidden-source-map

  与 source-map 相同，但不会为 bundle 添加引用注释。如果你只想 source map 映射那些源自错误报告的错误堆栈跟踪信息，但不想为浏览器开发工具暴露你的 source map，这个选项会很有用。

你不应将 source map 文件部署到 web 服务器。而是只将其用于错误报告工具。

• nosources-source-map

  创建的 source map 不包含 sourcesContent(源代码内容)。它可以用来映射客户端上的堆栈跟踪，而无须暴露所有的源代码。你可以将 source map 文件部署到 web 服务器。

这仍然会暴露反编译后的文件名和结构，但它不会暴露原始代码。

在使用 uglifyjs-webpack-plugin 时，你必须提供 sourceMap：true 选项来启用 source map 支持。

模块热替换(hot module replacement)

模块热替换(HMR - Hot Module Replacement)功能会在应用程序运行过程中替换、添加或删除模块，而无需重新加载整个页面。主要是通过以下几种方式，来显著加快开发速度：

• 保留在完全重新加载页面时丢失的应用程序状态。
• 只更新变更内容，以节省宝贵的开发时间。
• 调整样式更加快速 - 几乎相当于在浏览器调试器中更改样式。

在应用程序中

通过以下步骤，可以做到在应用程序中置换(swap in and out)模块：

• 应用程序代码要求 HMR runtime 检查更新。
• HMR runtime（异步）下载更新，然后通知应用程序代码。
• 应用程序代码要求 HMR runtime 应用更新。
• HMR runtime（同步）应用更新。

你可以设置 HMR，以使此进程自动触发更新，或者你可以选择要求在用户交互时进行更新。

在编译器中

除了普通资源，编译器(compiler)需要发出 “update”，以允许更新之前的版本到新的版本。“update” 由两部分组成：

• 更新后的 manifest(JSON)
• 一个或多个更新后的 chunk (JavaScript)

manifest 包括新的编译 hash 和所有的待更新 chunk 目录。每个更新 chunk 都含有对应于此 chunk 的全部更新模块（或一个 flag 用于表明此模块要被移除）的代码。

编译器确保模块 ID 和 chunk ID 在这些构建之间保持一致。通常将这些 ID 存储在内存中（例如，使用 webpack-dev-server 时），但是也可能将它们存储在一个 JSON 文件中。

在模块中

HMR 是可选功能，只会影响包含 HMR 代码的模块。举个例子，通过 style-loader 为 style 样式追加补丁。为了运行追加补丁，style-loader 实现了 HMR 接口；当它通过 HMR 接收到更新，它会使用新的样式替换旧的样式。

类似的，当在一个模块中实现了 HMR 接口，你可以描述出当模块被更新后发生了什么。然而在多数情况下，不需要强制在每个模块中写入 HMR 代码。如果一个模块没有 HMR 处理函数，更新就会冒泡(bubble up)。这意味着一个简单的处理函数能够对整个模块树(complete module tree)进行更新。如果在这个模块树中，一个单独的模块被更新，那么整组依赖模块都会被重新加载。

有关 module.hot 接口的详细信息，请查看 HMR API 页面。

在 HMR Runtime 中

这些事情比较有技术性……如果你对其内部不感兴趣，可以随时跳到 HMR API 页面或 HMR 用例。

对于模块系统的 runtime，附加的代码被发送到 parents 和 children 跟踪模块。在管理方面，runtime 支持两个方法 check 和 apply。

check 发送 HTTP 请求来更新 manifest。如果请求失败，说明没有可用更新。如果请求成功，待更新 chunk 会和当前加载过的 chunk 进行比较。对每个加载过的 chunk，会下载相对应的待更新 chunk。当所有待更新 chunk 完成下载，就会准备切换到 ready 状态。

apply 方法将所有被更新模块标记为无效。对于每个无效模块，都需要在模块中有一个更新处理函数(update handler)，或者在它的父级模块们中有更新处理函数。否则，无效标记冒泡，并也使父级无效。每个冒泡继续，直到到达应用程序入口起点，或者到达带有更新处理函数的模块（以最先到达为准，冒泡停止）。如果它从入口起点开始冒泡，则此过程失败。

之后，所有无效模块都被（通过 dispose 处理函数）处理和解除加载。然后更新当前 hash，并且调用所有 “accept” 处理函数。runtime 切换回闲置状态(idle state)，一切照常继续。

模块热替换 API(HMR API)

如果已经通过 HotModuleReplacementPlugin 启用了 HMR，则它的接口将被暴露在 module.hot 属性下面。通常，用户先要检查这个接口是否可访问，然后再开始使用它。举个例子，你可以这样 accept 一个更新的模块：

if (module.hot) {
    
    
  module.hot.accept('./library.js', function () {
    
    
    // 使用更新过的 library 模块执行某些操作...
  });
}

accept

接受(accept)给定依赖模块的更新，并触发一个回调函数来对这些更新做出响应。

module.hot.accept(
  dependencies, // 可以是一个字符串或字符串数组
  callback, // 用于在模块更新后触发的函数
);

使用 ESM import 时，将从依赖项中导入的所有符号自动更新。 注意：依赖项字符串必须与 import 中的 from 字符串完全匹配。 在某些情况下，甚至可以省略 callback。 在回调中使用 require()没有意义。

使用 CommonJS 时，您需要通过在 callback 中使用 require()来手动更新依赖项。 省略 callback 在这里没有意义。

decline

拒绝给定依赖模块的更新，使用decline方法强制更新失败。

module.hot.decline(
  dependencies, // 可以是一个字符串或字符串数组
);

dispose（或 addDisposeHandler）

添加一个处理函数，在当前模块代码被替换时执行。此函数应该用于移除你声明或创建的任何持久资源。如果要将状态传入到更新过的模块，请添加给定 data 参数。更新后，此对象在更新之后可通过 module.hot.data 调用。

module.hot.dispose((data) => {
    
    
  // 清理并将 data 传递到更新后的模块……
});

removeDisposeHandler

删除由 dispose 或 addDisposeHandler 添加的回调函数。

module.hot.removeDisposeHandler(callback);

status

取得模块热替换进程的当前状态。

module.hot.status(); // 返回以下字符串之一……

Status	描述
idle	该进程正在等待调用 check（见下文）
check	该进程正在检查以更新
prepare	该进程正在准备更新（例如，下载已更新的模块）
ready	此更新已准备并可用
dispose	该进程正在调用将被替换模块的 dispose 处理函数
apply	该进程正在调用 accept 处理函数，并重新执行自我接受(self-accepted)的模块
abort	更新已中止，但系统仍处于之前的状态
fail	更新已抛出异常，系统状态已被破坏

check

测试所有加载的模块以进行更新，如果有更新，则应用它们。

module.hot
  .check(autoApply)
  .then((outdatedModules) => {
    
    
    // 超时的模块……
  })
  .catch((error) => {
    
    
    // 捕获错误
  });

autoApply 参数可以是布尔值，也可以是 options，当被调用时可以传递给 apply 方法

可选的 options 对象可以包含以下属性：

options	描述
ignoreUnaccepted (boolean)	忽略对未接受的模块所做的更改。
ignoreDeclined (boolean)	忽略对拒绝的模块所做的更改。
ignoreErrored (boolean)	忽略接受处理函数，错误处理函数以及重新评估模块时抛出的错误。
onDeclined (function(info))	拒绝模块的通知者
onUnaccepted (function(info))	未接受模块的通知程序
onAccepted (function(info))	接受模块的通知者
onDisposed (function(info))	废弃模块的通知者
onErrored (function(info))	异常通知者

info 参数可能存在以下对象：

{
    
    
  type: "self-declined" | "declined" |
        "unaccepted" | "accepted" |
        "disposed" | "accept-errored" |
        "self-accept-errored" | "self-accept-error-handler-errored",
  moduleId: 4, // The module in question.
  dependencyId: 3, // For errors: the module id owning the accept handler.
  chain: [1, 2, 3, 4], // For declined/accepted/unaccepted: the chain from where the update was propagated.
  parentId: 5, // For declined: the module id of the declining parent
  outdatedModules: [1, 2, 3, 4], // For accepted: the modules that are outdated and will be disposed
  outdatedDependencies: {
    
     // For accepted: The location of accept handlers that will handle the update
    5: [4]
  },
  error: new Error(...), // For errors: the thrown error
  originalError: new Error(...) // For self-accept-error-handler-errored:
                                // the error thrown by the module before the error handler tried to handle it.
}

addStatusHandler

注册一个函数来监听 status 的变化。

module.hot.addStatusHandler((status) => {
    
    
  // 响应当前状态……
});

removeStatusHandler

移除一个注册的状态处理函数。

module.hot.removeStatusHandler(callback);

HMR 用例

模块热替换(Hot Module Replacement 或 HMR)是 webpack 提供的最有用的功能之一。它允许在运行时更新各种模块，而无需进行完全刷新。

HMR 不适用于生产环境，这意味着它应当只在开发环境使用

启用 HMR

配置 webpack-dev-server ，并使用 webpack 的内置 HMR 插件

HMR 修改样式

借助于 style-loader 的帮助，CSS 的模块热替换实际上是相当简单的。当更新 CSS 依赖模块时，此 loader 在后台使用 module.hot.accept 来修补(patch)

所以，可以使用以下命令安装两个 loader ：

npm i style-loader css-loader -D

接下来我们来更新 webpack 的配置，让这两个 loader 生效。

webpack.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const {
    
     CleanWebpackPlugin } = require('clean-webpack-plugin');
const webpack = require('webpack');

module.exports = {
    
    
  mode: 'development',
  entry: {
    
    
    main: './src/main.js',
  },
  output: {
    
    
    path: path.join(__dirname, 'dist'),
    filename: 'main.js',
  },
  devtool: 'eval-source-map',
  devServer: {
    
    
    contentBase: false,
    hot: true,
    open: true,
  },
  plugins: [new CleanWebpackPlugin(), new HtmlWebpackPlugin()],
  module: {
    
    
    rules: [
      {
    
    
        test: /\.css$/,
        use: [
          {
    
    
            loader: 'style-loader',
          },
          {
    
    
            loader: 'css-loader',
          },
        ],
      },
    ],
  },
};

src/textarea.js

module.exports = function () {
    
    
  const textarea = document.createElement('textarea');
  textarea.id = 'text';
  return textarea;
};
src/assets/main.css

#text {
    
    
  color: red;
}

src/main.js

import './assets/main.css';
import textarea from './textarea';

const textareaEl = textarea();
const body = document.body;
body.appendChild(textareaEl);

将 id 为 text 上的样式修改为 color: black，你可以立即看到页面的字体颜色随之更改，但并未刷新页面。

src/assets/main.css

#text {
    
    
  color: black;
}

HMR 修改 js

这里我们使用HMR API里的accept来修补(patch)

webpack.config.js 配置

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const {
    
     CleanWebpackPlugin } = require('clean-webpack-plugin');
const webpack = require('webpack');

module.exports = {
    
    
  mode: 'development',
  entry: {
    
    
    main: './src/main.js',
  },
  output: {
    
    
    path: path.join(__dirname, 'dist'),
    filename: 'main.js',
  },
  devtool: 'eval-source-map',
  devServer: {
    
    
    contentBase: false,
    hot: true,
    open: true,
  },
  optimization: {
    
    
    NamedModulesPlugin,
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin(),
    new webpack.HotModuleReplacementPlugin(),
  ],
};

我们还添加了 NamedModulesPlugin，以便更容易查看要修补(patch)的依赖.

src/textarea.js

module.exports = function () {
    
    
  const textarea = document.createElement('textarea');
  textarea.id = 'text';
  return textarea;
};

src/main.js

import textarea from './textarea';

let textareaEl = textarea();
const body = document.body;
body.appendChild(textareaEl);

// 判断是否开启模块热替换
if (module.hot) {
    
    
  module.hot.accept('./textarea.js', () => {
    
    
    console.log('Accepting the updated textarea module!');
    // 获取页面重新渲染前的值
    const val = textareaEl.value;
    // 移除Element
    body.removeChild(textareaEl);
    // 这里拿到的是最新的Element
    textareaEl = textarea();
    // 将value值写入
    textareaEl.value = val;
    // 添加Element
    body.appendChild(textareaEl);
  });
}

将 id 修改为 text1，你可以立即看到页面的 textarea 标签 id 也随之更改，但并未刷新页面。

src/textarea.js

module.exports = function () {
    
    
  const textarea = document.createElement('textarea');
  textarea.id = 'text1';
  return textarea;
};

Webpack 多环境多配置文件

开发环境(development)和生产环境(production)的构建目标差异很大。在开发环境中，我们需要具有强大的、具有实时重新加载(live reloading)或热模块替换(hot module replacement)能力的 source map 和 localhost server。而在生产环境中，我们的目标则转向于关注更小的 bundle，更轻量的 source map，以及更优化的资源，以改善加载时间。建议为每个环境编写彼此独立的 webpack 配置。

因为生产环境和开发环境的配置只有略微区别，所以将共用部分的配置作为一个通用配置。使用webpack-merge工具，将这些配置合并在一起。通过通用配置，我们不必在不同环境的配置中重复代码。

安装webpack-merge

npm i webpack-merge -D

示例

build/webpack.base.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const {
    
     CleanWebpackPlugin } = require('clean-webpack-plugin');

module.exports = {
    
    
  entry: {
    
    
    main: './src/main.js',
  },
  output: {
    
    
    path: path.join(__dirname, '../dist'),
    filename: 'main.js',
  },
  plugins: [new CleanWebpackPlugin(), new HtmlWebpackPlugin()],
  module: {
    
    
    rules: [
      {
    
    
        test: /\.css$/,
        use: [
          {
    
    
            loader: 'style-loader',
          },
          {
    
    
            loader: 'css-loader',
          },
        ],
      },
      {
    
    
        test: /\.txt$/,
        use: {
    
    
          loader: 'raw-loader',
        },
      },
      {
    
    
        test: require.resolve('../src/answer.js'),
        use: {
    
    
          loader: 'val-loader',
        },
      },
      {
    
    
        test: /\.(png|jpge|jpg|git|svg)$/,
        use: {
    
    
          loader: 'file-loader',
          options: {
    
    },
        },
      },
    ],
  },
};

webpack.dev.config.js

const webpack = require('webpack');
const {
    
     merge } = require('webpack-merge');
const baseConfig = require('./webpack.base.config');

module.exports = merge(baseConfig, {
    
    
  mode: 'development',
  devtool: 'eval-source-map',
  devServer: {
    
    
    contentBase: false,
    hot: true,
    open: true,
  },
  plugins: [
    new webpack.NamedModulesPlugin(),
    new webpack.HotModuleReplacementPlugin(),
  ],
});

webpack.pro.config.js

const path = require('path');
const UglifyJSPlugin = require('uglifyjs-webpack-plugin');
const merge = require('webpack-merge');
const baseConfig = require('./webpack.base.config');

module.exports = merge(baseConfig, {
    
    
  mode: 'production',
  devtool: false,
  plugins: [new UglifyJSPlugin()],
});

Tree Shaking

Tree Shaking 是一个术语，通常用于描述移除 JavaScript 上下文中的未引用代码(dead-code)。它依赖于 ES2015 模块系统中的静态结构特性，例如 import 和 export。这个术语和概念实际上是兴起于 ES2015 模块打包工具 rollup。

你可以将未引用代码(dead-code)理解为枯树叶，使用 Tree Shaking 「摇掉」枯树叶

webpack 的 mode 为 production 时，会自动开启 Tree Shaking

optimization.usedExports

boolean = true

负责标记「枯树叶」

代码分离

代码分离是 webpack 中最引人注目的特性之一。此特性能够把代码分离到不同的 bundle 中，然后可以按需加载或并行加载这些文件。代码分离可以用于获取更小的 bundle，以及控制资源加载优先级，如果使用合理，会极大影响加载时间。

有三种常用的代码分离方法：

• 入口起点：使用 entry 配置手动地分离代码。
• 防止重复：使用 SplitChunksPlugin 去重和分离 chunk。
• 动态导入：通过模块的内联函数调用来分离代码。

Webpack 构建缓存机制-hash

hash

这边我们将长度指定为 8 位

module.exports = {
    
    
  mode: 'production',
  entry: './src/index.js',
  output: {
    
    
    filename: '[name].[hash:8].bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

hash 是跟整个项目的构建相关，只要项目里有文件更改，整个项目构建的 hash 值都会更改，并且所有文件都共用相同的 hash 值

chunkhash

根据不同的入口文件(Entry)进行依赖文件解析、构建对应的 chunk，生成对应的哈希值。

module.exports = {
    
    
  mode: 'production',
  entry: './src/index.js',
  output: {
    
    
    filename: '[name].[chunkhash:8].bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

将样式作为模块 import 到 JavaScript 文件中的，生成的 chunkhash 是一致的

如果我们修改了 js 的内容，css 的打包名称也会改变

contenthash

ontenthash 是针对文件内容级别的，只有自己的文件内容变了，hash 值才会改变

构建目标(Target)

target string | function(compiler)

告知 webpack 为目标(target)指定一个环境。

外部扩展(Externals)

externals 配置选项提供了「从输出的 bundle 中排除依赖」的方法。相反，所创建的 bundle 依赖于那些存在于用户环境(consumer’s environment)中的依赖。此功能通常对 library 开发人员来说是最有用的，然而也会有各种各样的应用程序用到它。

用户(consumer)，在这里是指，引用了「使用 webpack 打包的 library」的所有终端用户的应用程序(end user application)。

externals

string array object function regex

防止将某些 import 的包(package)打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖(external dependencies)。

#例如，从 CDN 引入 jQuery，而不是把它打包：
index.html

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

webpack.config.js

externals: {
    
    
  jquery: 'jQuery'
}

这样就剥离了那些不需要改动的依赖模块，换句话，下面展示的代码还可以正常运行：

import $ from 'jquery';

$('.my-element').animate(...);