由于文章篇幅较长，为了更好的阅读体验，本文分为上、中、下三篇：
-
上篇介绍了什么是 webpack，为什么需要 webpack，webpack 的文件输入和输出
-
中篇介绍了 webpack 在输入和输出这段中间所做的事情，也就是 loader 和 plugins
-
下篇介绍了 webpack 的优化，以及在开发环境和生产环境的不同用法
用过上面两篇较长的篇幅，我们终于了解了 webpack 的整体工作流程。在最后一篇，将会介绍一些零碎但也很重要的知识点。
tree-shaking
tree-shaking 这个技术在 webpack2 就已经被添加进来了，作用是在打包过程中，将模块内没有使用的代码删除，从而减小打包后的文件体积。
这个单词表面的意思是，有一棵小树，你去抖动这棵树，那么树上多余没用的树叶就会掉落，那在代码中具体是什么样子呢。假设我们现在将一些常用的方法都封装在了 util.js 这个文件中：
// util.js
function add(...args) {
return args.reduce((prev, currrent, index) => {
return prev + currrent;
}, 0);
}
function multiply(...args) {
return args.reduce((prev, currrent, index) => {
return prev * currrent;
}, 1);
}
export {
add,
multiply
}
然后我们在 index.js 中需要用到 add 这方法：
// index.js
import { add } from './util.js';
add(1, 2);
add(1, 2, 3);
这样打包后的代码是不含有 multiply 这个函数的，这就是 tree-shaking 的作用。
splitChunk
现在我们再回顾一下 webpack 打包过程
- 以 entry 为起点，将所依赖的模块组织成一个树形的结构
- 通过不同的 loader 对不同的文件进行编译
- 使用 plugins 对文件打包后的文件进行特定的操作
- 根据 output 将打包后的文件输出到指定的位置
如果只有一个入口文件，最终也只会打包出一个文件(下文用 chunk 表示，每打包出的一个文件就叫一个 chunk)（排除动态加载的情况(import())）。这里有一个很明显的缺陷，就是将所有的模块打包成一个文件，打包后的体积一定会很大。同时，如果我们使用了 chunkhash 做文件缓存的话，每次项目修改的时候，无论修改哪个文件，即使是修改了一个换行，chunkhash 的值都会发生改变，那么每次改动上线之后，用户都要重新加载这个巨大的文件，这样用户体验非常糟糕。如果你说我不做文件缓存，那么由于浏览器缓存的原因，用户首次加载的文件会被缓存到本地，下次即使你更新了代码，用户执行的还是首次加载的文件，这样老板会找你聊天的。
为了解决这个问题，我们可以考虑设置多个入口文件，就像在介绍 entry 的例子代码中那样：
// webpack.config.js
module.exports = {
entry: {
login: 'src/login.js',
logout: 'src/logout.js',
}
}
通过这样的配置，我们就可以将 login.js 和 logout.js 打包成两个文件，而且修改其中一个文件不会影响到另一个的 chunkhash。看起来好像已经解决了上面的问题，但是我们再结合实际的项目深入的分析一下，我们通常会在项目中引入一些类库，比如常见的 lodash ，假设 login.js 和 logout.js 中都用到了 lodash ，这就需要在这个两个文件中显式的 import _ from 'lodash'; 这样一来，打包出来的两个文件都包含了 lodash ，这就属于重复引用了，另外如果我们的项目是单页应用，理应只有一个入口，在需要的时候再去加载 login.js 或 logout.js 的代码。
所以我们要解决我们一开始的问题，应该从下面两个点出发：
- 分离代码中公共的部分，打包成一个或多个chunk
- 将不需要立刻执行的代码分离出来，打包成多个 chunk ，然后通过动态加载的加载这些chunk
针对第一点，我们可以使用 webpack 提供的 SplitChunksPlugin 插件，这个插件和上面介绍的 minimize 一样，需要在 optimization.splitChunks 中配置。在 production 模式下 webpack 会默认做一下代码分离的工作，但是没多大的卵用，所以还是需要我们自己动手配置。
第一步先将来自 node_modules 中的包分离出来，因为这些都是项目所依赖的第三方库，我们是不会改动的（除非升级版本），这些可以做通过 chunkhash 做长期缓存，我们把这写代码打包为 chunk-vendors
// webpack.config.js
module.exports = {
entry,
output: {
path: './dist',
filename: '[name].[chunkhash:8].js' // 只取chunkhash的前8位
},
optimization: {
splitChunks: {
cacheGroups: {
vendors: {
name: `chunk-vendors`,
test: /[\/]node_modules[\/]/,
priority: -10,
chunks: 'initial'
}
}
}
}
}
在上面的配置中，我们用 cacheGroups 将 node_modules 的代码全部分离出来。 cacheGroups 直译成中文就是缓存组，其实就是存放分离代码块规则的对象，第一个对象的 key 值是 vendors ，这个 key 值没什么用，主要还是看对应的 val 。
- name：分离后打包出的文件名称。我们设置为 chunk-vendors ，那么打包出来的文件就叫 chunk-vendors.js 。因为在 output.filename 设置了 chunkhash:8，所以最终打包出的文件名称是 chunk-vendors.ac96737b.js 。后面的一串字符就是 chunkhash 的前8位。前面介绍过 chunkhash 是每一个打包出来的文件的 hash ，只要文件的内容没有改变，这个值就不会发生变化，所以只要不对我们依赖的包进行版本升级，或者增加新的包，这个值就不会变动，因此可以用这个办法进行长期缓存。
- test：用于匹配的文件位置，
test: /[\/]node_modules[\/]/表示所有来自 node_modules 下面的代码，可以填写具体的路径 - priority：权重，这个值还是很重要的，webpack 会优先分离权重高的 cacheGroups 。
- chunks：作用范围，可以设置为 async 表示对异步模块起作用， initial 表示对初始模块起作用， all 则表示对所有模块起作用。
如果打包出的 chunk-vendors 体积很大，而且包含一些经常升级的依赖，那么我们可以继续做拆分
// webpack.config.js
module.exports = {
entry,
output: {
path: './dist',
filename: '[name].[chunkhash:8].js'
},
optimization: {
splitChunks: {
cacheGroups: {
vendors: {
name: `chunk-vendors`,
test: /[\/]node_modules[\/]/,
priority: -10,
chunks: 'initial'
},
vue: {
name: 'chuank-vue',
test: /[\/]node_modules[\/]vue[\/]/,
priority: 10,
chunks: 'initial'
}
}
}
}
}
这样我就将 vue 分离成单独一个 chunk 了，不仅减小了 chunk-vendors 的体积 ，当我们升级 vue 版本的时候，也不会影响 chunk-vendors 的 chunkhash 。注意：不要忘了设置 priority 。
除了将 node_modules 中的类库分离出来，我们自己写的代码中也有些公共的部分，比如在讲 tree-shaking 提到了 util.js ，作为一个工具方法，跟定会在项目中好多处用到，那么我们也可以将会这个公共代码分离出来：
// webpack.config.js
module.exports = {
entry,
output: {
path: './dist',
filename: '[name].[chunkhash:8].js'
},
optimization: {
splitChunks: {
cacheGroups: {
common: {
name: `chunk-common`,
minChunks: 2,
priority: -20,
chunks: 'initial',
reuseExistingChunk: true
}
}
}
}
}
在上面的配置中，我们把被依赖超过两次（minChunks: 2）的 chunk 都分离到了 chunk-common.f4786e34.js 中。
在解决了对公共代码的分离，下一步即使处理动态加载的代码，之一部分相对简单一些，就像在介绍 babel 时提到的那样，通过 import() 来切分动态加载的代码。
webpack 在将我们的代码打包后，也会生成一些在运行时所必须的代码，这些代码默认会打包进主文件中，我们也可以将它分离出来单独打包成一个文件，这需要在 optimization.runtimeChunk 中单独配置：
// webpack.config.js
module.exports = {
entry,
output,
optimization: {
runtimeChunk: {
name: 'manifest'
}
}
}
这样就可以将运行时的代码也分里出来，打包为 manifest.js。
其实代码拆分是需要反复尝试的，一般情况下我们只会将 node_modules 里的包分离成一份（chunk-vendors.js）， 业务中公共的代码分离成一分（chunk-common.js），剩下的都放在了主模块（main.js） 和动态加载的 chunk 中了。但是由于项目的不同，这种方式未必是最好的，所以这需要我们反复的去尝试一各种分离的方式，为了让我们对打包后的代码有更为直观的认识，我们可以借助 webpack-bundle-analyzer 来帮我们很直观的看到打包后每一个 chunk 的大小。
webpack-dev-server
在上面的介绍中，都是面向打包的，也就是说我们默认代码是无误可以直接打包上线运行，当然这是不可能滴，实际开中需要配合 Google 和 fuck 来 debug 代码，如果用上面的方法来 debug 我相信不管是谁，都会想砸电脑的，因为每次 debug 都要重新的打包，然后再想办法再本地启动一个web服务，用来托管我们打包出的静态文件。那么 webpack 可不可以帮我做到这两点呢:
- 监听文件变化，自动重新编译
- 创建一个web服务，用来托管打包后的静态文件，方便本地调试
为了解决上面两点，webpack 提供了 webpack-dev-server 这个包，它可以轻松的帮助我们实现上面两功能，这个包需要单独安装一下
npm i webpack-dev-server -D
然后在 npm script 中添加一行 ：
// package.json
{
"scripts": {
"dev": "webpack-dev-server --mode development",
"build": "webpack --mode production"
}
}
这时候在命令行中执行 npm run dev ，便会在本地启动一个Web服务,当命令行中出现 Compiled successfully 便表示服务启动成功，然后打开浏览器，输入 localhost:8080 便可以直接访问项目了。当源代码发生变化时，便会自动重新编译，然后刷新浏览器。
webpack-dev-server 同样也提供了一些配置选项，可以在配置文件的 devServer 中进行配置：
// webpack.config.js
module.exports = {
entry,
output,
devServer: {
port: 8080, // 设置端口为8080，默认就是8080
open: true, // 编译完成后自动打开浏览器
historyApiFallback: true, // 如果你的项目使用了 HTML5 history API ，开启此项可以将所有的跳转将指向index.html
}
}
这些配置也可以以参数的形式添加在加命令行后面，但是有的配置只能以参数的形式使用，比如我们想查看编译的进度，就需要加上 --progress :
// package.json
{
"scripts": {
"dev": "webpack-dev-server --mode development --progress",
"build": "webpack --mode production"
}
}
学会了如何使用，在简单的介绍一下 webpack-dev-server 的工作原理，webpack-dev-server 是一个基于 express 封装的 Web 服务，当我们在执行 webpack-dev-server 时候，虽然可以看到打包之后的运行效果，但是实际上并没有生成打包后的文件，这是因为 webpack-dev-server 将打包后的内容放在了内存中，当某一个源代码文件发生变更的时候，它也不会重新的再将所有的文件打包一遍，而是只更新了一部分文件，这样的好处是可以加快重新编译的速度，加大程度的减少了开发模式下的编译时间。
讲到这里，你可能也意识到了，如果是开发模式下，有许多事情都不需要做。比如不需要设置 output ，不需要对代码压缩，不需要分离 css 和 js 等等，如果省去这些工作，首次编译的速度又会有大幅度的提升，这是一个优化点，会在后面讲到。
HMR
HMR (hot module replace) 模块热替换，在不刷新页面的情况下更新代码。
在引入了 webpack-dev-server 之后，我们可以做到监听源代码变化，然后刷新浏览器及时看到修改效果。但是在前端开发中，每一步操作往往都伴随着状态和 dom 的变化，比如我们开发一个定外卖的网站，此时正在调试购物车功能，先加了一份煲仔饭，为了满减，再加一份荷包蛋，但是这时候后出现了bug，加了荷包蛋还是没有满减，原来是计算满减的方法写错了，修复这个bug之后，我们发现页面刷新了，回到最开始的样子，于是又要从选择店铺开始在走一遍流程。那可不可以在修复计算满减的方法之后，不要刷新页面也能看到正确的效果呢？这就是 HMR 实现的功能了。
开启 HMR 需要将 devServer.hot 设置为 true ，然后在 plugins 中添加 HotModuleReplacementPlugin 插件，该插件是 webpack 自带的一个插件：
// webpack.config.js
module.exports = {
entry,
output,
plugins: [
new webpack.HotModuleReplacementPlugin()
]
devServer: {
hot: true,
/* 其他配置 */
/* ... */
}
}
还有一种更简便的方法来开启 HRM ，那就是在命令行中添加参数 --hot ，然后在执行 npm run dev 的时候也会自动添加 HotModuleReplacementPlugin 插件。
现在我们在 webpack 中开启了 HMR 功能，webpack 可以将老模块替换为编译后的新模块，但是从浏览器层面考虑，浏览拿到新模块之后，并不知道要做什么处理，就像我们前面举的例子中提到，在修改计算满减方法之后，我们希望重新执行一遍这个方法，很明显这个需求不太现实，浏览名没那么聪明。所有这就需要我们显式的用代码来告诉浏览器来做哪些事情。
我们可以在项目代码中通过 module.hot 来判断是否启用了 HMR ，通过 module.hot.accept 来处理模块更新后的要做的事情，现在假设我们的项目入口文件是 index.js ，还有一个 util.js 里面封装了 add 方法：
project
├── src
│ ├── index.js
│ ├── util.js
│ └── index.html
└── webpack.config.js
// util.js
function add(...args) {
return args.reduce((prev, currrent, index) => {
return prev + currrent;
}, 0);
}
export { add }
然后我们在 index.js 中导入 add 方法，并且将计算结果显示在页面上：
// index.js
import { add } from './util.js';
const h2 = document.createElement('h2');
h2.innerHTML = add('1', '2');
document.body.appendChild(h2);
将项目跑起来之后，发现 add 方法计算的结果错了，经排查发现原来 add 方法忽略了对 string 类型的转换，只要修改一下 util.js 中的 add 函数就好了：
// util.js
function add(...args) {
return args.reduce((prev, currrent, index) => {
return prev + currrent * 1;
}, 0);
}
export { add }
这时候可以发现，页面中虽然显示了正确的结果，但是页面刷新了，而我们希望的是在页面不刷新的情况下显示正确结果，这时候就要在 index.js 添加热更新后需要执行的代码了：
// index.js
import { add } from './util.js';
const h2 = document.createElement('h2');
h2.innerHTML = add('1', '2');
document.body.appendChild(h2);
if (module.hot) {
module.hot.accept('./util.js', () => {
h2.innerHTML = add('1', '2');
});
}
这样再去修改 add 方法的时候，h2 显示的内容会发生变化，但是页面却不会刷新，这才是我们想要的热更新。
讲到这里你可能已经发现，实现一个完美的热更新，难点不是在 webpack 的配置，而是在我们的项目代码中，我们要针对所有需要热更新的模块加上热更新之后的回调( module.hot.accept )，不过社区中已经提供了一些 loader 使 HMR 与各种框架平滑地进行交互 https://webpack.js.org/guides/hot-module-replacement/#other-code-and-frameworks ，
如果需要样式热更新的话，我们需要判断当前的环境变量是否为 development ，然后将 MiniCssExtractPlugin.loader 换成 style-loader ，因为 MiniCssExtractPlugin 还不支持 HMR ：
// webpack.config.js
const styleLoader = process.env.NODE_ENV === 'development' ? 'style-loader' : MiniCssExtractPlugin.loader;
module.exports = {
entry,
output,
module: {
rules: [{
test: /.css$/,
use: [styleLoader, 'css-loader']
}]
}
}
content-base
在 plugins 这一章节中，提到了 copy-webpack-plugin 这个插件，它是用来将一些静态资源拷贝到打包后的目录，但是在开发环境下，我们是通过 webpack-dev-server 创建一个 Web 服务，它的根目录默认是配置文件所在的目录，所以在开发模式下，如果需要请求一些静态资源，那么我们就需要设置一下 contentBase 。
假设我们的静态资源放在了项目根目录下的 static 文件夹下面，而且配置文件 webpack.config.js 也放在了项目根目录下，那么我么就可以将 devServer.contentBase 设置为 static ：
// webpack.config.js
module.exports = {
entry,
output,
devServer: {
contentBase: 'static'
}
}
假设 static 下面有一个图片 logo.png ，我们就可以通过 localhost:8080/logo.png 来访问这张图片了。
public-path
在介绍 output.publicPath 的时候提到，这个值并不会影响打包后输出的文件路径，他只是设置在线上运行的时候，所请求的资源路径，当我们在 webpack-dev-server 这个 Web 服务下调试我们的代码的时候，可能也会出现和类型的情况，这时候就需要设置一下 devServer.publicPath 了。它 output.publicPath 的区别的是 一个作用于线上环境，一个作用于我们调试的开发环境。
proxy
在开发过程，经常需要调用后端提供的接口，一般情况会把接口部署在测试环境，比如 http://test.api.com 然后我们在项目中通过 ajax 的方式去调用。由于同源策略，我们在开发的时候通过 webpack-dev-server 启动的 Web 服务的域是 localhost:8080 ，很明显跨域了，接口无法调用了。这个时候有两种办法解决，一是在测试上环境上配置 cors ，将我们的 localhost 加入允许跨域的名单；二是我们在本地利用 node 去请求这个接口，然后再将请求内容发送给前端，在整个过程中 node 扮演的角色就是一个可靠的跑腿子，你去把请求交给它，它把请求送给测试环境，测试环境把响应交给它，它再把响应送到你这边。
在 webpack-dev-server 集成了中间件 (http-proxy-middleware)[https://github.com/chimurai/http-proxy-middleware] 可以很轻松的完成接口转发，比如我们想将所有的以 /api 开头的请求都转发到 http://test.api.com 只要在 devServer.proxy 像下面这样配置即可：
// webpack.config.js
module.exports = {
entry,
output,
devServer: {
proxy: {
'/api': 'http://test.api.com'
}
}
}
devServer.proxy 暴露出的配置项和 (http-proxy-middleware)[https://github.com/chimurai/http-proxy-middleware] 的配置项完全一样，具体可以点击链接查看。
mock
后端已经写好的接口我们我们可以用转发的方式调用，而对于还没有写好的接口我们可以通过 mock 的方式来调用，这样可以解决因为接口调用通而导致我们开发不畅的问题。因为 webpacl-dev-server 是基于 express 封装了，并且将 express 的实例暴露在了 devServer.before 和 devServer.after 这两个配置项下面，所以我们完全可以将后端没有写好的接口在 devServer.before 通过 express 去 mock 。假设我们现在需要调用 /api/user/creation 这个接口来创建用户，我们可以这样 mock
// webpack.config.js
module.exports = {
entry,
output,
devServer: {
befor(app) {
app.post('/api/user/creation', (req, res) => {
// some code
res.json({success: true});
});
}
}
}
如果你需要 mock 的接口后端，那你完全可以像写 express 那样去写接口，当然有些常用的中间件需要我们自己去安装。
其它
source-maps
webpack 打包压缩之后的代码可读性几乎为零，同时也不方便调试，这时候可以通过设置 devtool 选项来帮助我们在开发环境调试，具体效果是：在 chrome 中(其它高级浏览器同样支持)打开控制台，我们可以在 Sources 中看到一个以 webpack:// 开头的资源，里面的内容和我们编写代码大致相同(这取决于 devtool 的值)。
由于 devtool 会影响打包的速度和打包后的代码质量，所以在生产环境的构建中，不建议开启此项(默认为none)，只要在开环境设置为 eval-source-map 即可。其它配置和打包速度可以参考 官网 。
alias
当项目的目录结构越来越深，模块变得越来越多的时候，模块间的引用会变得很混乱，时常会看到下面这样的代码：
import ComponentA from '../../../../../components/a.component.js';
import ServiceA from '../../../../../service/a.service.js';
有没有想骂人的冲动？这时候可以使用 webpack 的 alias 选项来解决这个问题，配置文件的内容如下：
// webpack.config.js
module.exports = {
entry,
output,
resolve: {
alias: {
'@': path.resolve(__dirname, "src"),
'components': path.resolve(__dirname, "src/components"),
'services': path.resolve(__dirname, "src/services"),
}
}
}
上面的配置表示为 src、src/components、src/services 分别设置一个别名，我们就可以在代码中用 @ 表示相对路径 src 而不必再使用 ../../ 一层一层的向上查找了。假设我们现在的项目结构是下面这样子:
project
├── src
│ ├── components
│ └── services
└── webpack.config.js
这样我们可以在任意文件夹下的代码内使用 @ 来表示根目录 src/，使用 components 来表示路径 src/components/ ，所以上面例子中的代码可以在简化为：
import ComponentA from '@/components/a.component.js';
import ServiceA from 'services/a.service.js';
这样配置之后，webpack 在打包编译的时候能识别简化之后的路径，但是编辑器却未必能识别，这又给我们开发带来了一些困扰，如果你是 vscode 用户的话，这个问题可以很好的解决。只要在项目的根目录添加一份配置文件 jsconfig.json 即可，配置文件的内容如下：
{
"compilerOptions": {
"baseUrl": ".", // 根目录
"paths": {
"@/*": [ "./src/*" ],
"components/*": [ "./src/components/*" ],
"services/*": [ "./src/services/*" ],
}
}
}
这个配置文件和 webpack 是没有关系的，它是给 vscode 用的，想请可以查看这里：https://code.visualstudio.com/docs/languages/jsconfig
extensions
在原生的 JavaScript 中，使用 import 加载一个模块是可以不用写文件的扩展名的，nodejs 中的 require 也是一样，就像这样：import ModuleA from 'a' ，现在有了 loader 我们也希望 import 其它类型文件的时候也不写扩展名，比如
import styles from '@/styles/common';
import html from '@/tpl/login';
只需在 webpack 中配置 extensions 即可，具体代码如下：
// webpack.config.js
module.exports = {
entry,
output,
resolve: {
extensions: ['.js', '.json', '.css', '.html']
}
}
该选项的值是一个数组，默认值为 ['.js', '.json'] ，当我们手动配置之后，默认值会被覆盖，所以为了不影响之前的写法，要在配置中将 .js 和 .json 也加上。
个人建议不要配置此项，尽量把文件的扩展名写全，这样不仅可以知道引入的文件是什么类型，而且在打包的时候速度也相对快一些。
externals
开发一个 Web 项目肯定会用到第三方的类库比如 jQuery、lodash 等，有人会选从 npm 下载，有人会选择从 cdn 加载。这两种方式使用起来都很简单：
- 从 npm 下载的包只需在用到的时候
import就行了：import _ from 'lodash' - 从 cdn 加载类库只要在 html 页面通过
script引入之后（注意引用顺序），便可以在任何地方使用
但是从 cdn 引入的资源在开发过程有一个很不好的地方：既然已经是模块化开发了，突然冒出一个全局变量会让人觉得很莫名其妙，而且这个变量也不能类型提示。
那可不可以这样子呢：
- 从 cdn 加载第三方类库（速度快）
- 在代码中依然使用
import的方式来引入资源（代码模块清晰） - 打包的时候排除从cdn加载的资源（减小打包后的代码体积）
答案是可以的，配置一下 externals 就可以轻松实现，以 jQuery 为例，具体代码如下：
// webpack.config.js
module.exports = {
entry,
output,
externals: {
jquery: 'jQuery'
}
}
在代码中就可以这样使用 jQuery :
import $ from 'jquery';
$(() => {
console.log('hello jQuery');
});
而且打包的时候会自动的把 jquery 排除掉。
从上面的配置中可以看出，externals 是一个对象，它的 key (jquery) 对应的是代码中引入的包名，也就是 from 后面的字符串，它的 val (jQuery) 就是暴露在全局的变量名，jQuery 暴露在全局的变量名为 jQuery 和 $ ，所以这里换成 $ 同样是可以的。
所以上面的代码可以理解为是下面这种写法：
const $ = window.jQuery;
$(() => {
console.log('hello jQuery');
});
如果想对这个选项有更多的理解，可以参考这里：https://github.com/zhengweikeng/blog/issues/10
分离配置文件
上面的配置中，有的是适用于生产环境的，有的是适用于开发环境的，所以我们要将配置文件做一下分离。在项目中创建 build 文件夹，用来存放我们的构建脚本，在 build 中创建 webpack.common.js 我们可以将一些通用的配置写在这里面，比如 entry、output、loader 等等。然后我们在创建 webpack.prod.js 和 webpack.dev.js 两份配置文件，分别用来编写打包和开发是的脚本，已经在webpack.common.js 中写好的配置，就不需要在写了。然后我们利用 webpack-merge 将通用的配置分别和 dev、prod 的配置合并：
// build/webpack.prod.js
const merge = require('webpack-merge');
const webpackCommonConfig = require('./webpack.common');
module.exports = merge(webpackCommonConfig, {
/** 针对打包到生产环境的配置 */
});
最后再利用 npm script 设置不同的脚本
{
"scripts": {
"dev": "webpack-dev-server --mode development --color --progress --config build/webpack.dev.js",
"build": "node build/build.js"
}
}
这里我已经写好一份可以直接使用的配置，大家可以参考一下 webpack-workbench https://github.com/onlymisaky/webpack-workbench