【转】Webpack 快速上手（上）

嫌啰嗦想直接看最终的配置请戳这里 webpack-workbench (https://github.com/onlymisaky/webpack-workbench)

由于文章篇幅较长，为了更好的阅读体验，本文分为上、中、下三篇：

上篇介绍了什么是 webpack，为什么需要 webpack，webpack 的文件输入和输出
中篇介绍了 webpack 在输入和输出这段中间所做的事情，也就是 loader 和 plugins
下篇介绍了 webpack 的优化，以及在开发环境和生产环境的不同用法

序

用两个自问自答来当作序吧：

Q：为什么要写这篇文章？
A：因为我在将自己的一个项目 AngularJS-ES6 (https://github.com/onlymisaky/AngularJS-ES6) 从 webpack3.x 升级到 4.x 的时候发现，作为一个熟练的 GitHub 搬运工，改起来还是很费力，主要是因为对其没有一个更完整的认知，因此有必要写一篇文章强化认知。
Q：既然是写给自己看的，那对于其他人有帮助吗？
A：如果你对 webpack 有少许的了解（至少知道webpack是干什么用的），那这篇文章应该还是有帮助的。

Why webpack？

一个工具的诞生，必然有其诞生的原因，也许是为了简化工作，也许是为了解决某些痛点，也可能是今年的kpi压力很大...

今天的主角 webpack 的诞生就是为了解决前端开发长久以来的痛点：模块化 ，这是也它的前辈 grunt 和 gulp 所不具备的功能。

回想一下那个前端还被称作切图仔的时代，我们是怎么组织多个 .js 文件的：

<script src="a.js"></script>

<script src="b.js"></script>

<script src="c.js"></script>

且不说这样写有多low，就单从代码维护角度来说，b.js 可能使用了 a.js 中的某个方法； c.js 同样如此，可能还用到了 b.js 中的某些方法。单看每个文件，是根本不知道这些方法是哪来的，也不清楚这三个文件之间的依赖关系的。

为了解决的这个问题，requirejs 诞生了，这是一套 AMD 的模块化实现方案。而此时 node 已经出现有些时日，其遵循的是 CommonJS ，同样是 JavaScript 模块化，却有两套实现方案，语法也不一样。于是又出现了 CMD 和其实现 seajs ，它是为了让服务端模块化和浏览器端模块化的差异能够最小化。

以上这些都是前辈们对 JavaScript 模块化的探索，虽然不是标准，但却推动了标准的发展，于是在 ES6 中，终于有了标准的、原生的模块化方案了，然鹅...

浏览器厂商：标准是标准，至于什么时候实现，fucked say (日后再议)。虽然现在大部分浏览器内核都实现了原生的模块化，但是我们不能确保用户都已将浏览器更新至最新了。

所以，在所有浏览器都实现模块化标准之前，我们还是不能够愉快的使用 import 和 export ，于是 webpack 来了，给乡亲们带了希望，让乡亲们再也不用看浏览器脸色，从此过上了没羞没臊幸福的生活了。

简单介绍

为了有更好更清晰的认识，建议读者跟着文章一起做一遍，可以先创建一个新的文件夹 learn-webpack ，在该目录中打开命令行，输入 npm init 命令初始化 package.json 文件。

安装

npm i webpack webpack-cli -D

可以全局安装，也可以本地安装，建议本地安装，因为 webpack 不同的版本之间还是有一定的差异，为了避免这个问题，我们选择本地。

在上面安装命令中，除了安装了 webpack 外，还安装了 webpack-cli 。那么这个工具是干什么用的？在 webpack4.x 之后，webpack 把命令行单独提取出来了，也就是说，我们想在命令行中执行 webpack xxx 等命令时，就需要先安装 webpack-cli 。所以如你的使用的4.x版本的 webpack ，还需要额外安装一下 webpack-cli 。

使用

webpack 的使用还是比较简单的，并且提供了三种使用方法：

不使用配置文件

webpack <entry> <output>

entry：要打包的文件，可以是一个文件，也可以是一组文件。

output：打包后生成的文件。

例如将 ./src/index.js 打包到 dist/app.js

webpack ./src/index.js dist/app.js

使用配置文件

不使用配置文件的方式显然不够灵活多变，所以通常都是先编写 webpack 配置文件，然后根据配置文件内容进行打包。在根目录下创建 webpack.config.js 文件，然后在命令行中输入 webpack ，webpack 会自动读取 webpack.config.js 中的配置内容，然后进行打包，下文将会着重介绍如何编写配置文件。

在node中启动

const webpack = require('webpack');

webpack({

  /* webpack配置内容 */

}, (err, stats) => {

  /* 打包后回调 */

});

npm script

在使用第二种方式的时候，我们也可以将一些配置内容以参数的形式添加在命令后面，比如我们想设置环境为 production ，可以在 webpack.config.js 中将 mode 设置为 production ，也可以在命令后面添加 --mode production ：

webpack --mode production

如果还需要其他的配置参数，可有继续在后面添加。这样做的好处是可以将一些多变的参数从配置文件中抽离出来，使用起来很灵活。

但是如果参数太多，每次使用的时候又要敲好多命令，可能还会敲错，为了方便管理我们可以将这些命令全部保存在 package.json 的 scripts 属性中：

{

  "scripts": {

    "dev": "webpack --mode development",

    "build": "webpack --mode production"

  }

}

这样就可以通过 npm run build 命令进行打包了。

核心概念

经常看到有人抱怨 webpack 太难太复杂了，“我们万事俱备，就差一个 webpack 配置工程师了”。确实如此，相比于 gulp 简洁的 api ，webpack 确实复杂了许多。

其实仔细的梳理一下，webpack 最重要也就4个核心概念：

entry 入口
output 出口
loader 模块转换器
plugins 插件

除了这四个核心的概念，剩下的那些都是为了优化代码、让我们能有更好的开发体验而设计的。

mode

开头先讲一个 webpack4 中新增的选项：mode。可能是受 parcel 的刺激，webpack4 终于也可以零配置打包了，主要原因是 webpack 终于明白了一个道理：约定大于配置。

model 的值有三种：production、development、none ，分别表示不同模式。

在 production 模式下，会默认启用下面这些插件：

process.env.NODE_ENV 的值设为 production
FlagDependencyUsagePlugin：删除无用代码
FlagIncludedChunksPlugin：删除无用代码
ModuleConcatenationPlugin：作用域提升
NoEmitOnErrorsPlugin：编译出现错误，跳过输出阶段
OccurrenceOrderPlugin
SideEffectsFlagPlugin
UglifyJsPlugin：js代码压缩

在 development 模式下，会默认启用下面这些插件：

process.env.NODE_ENV 的值设为 development
devtool 设置为 evel
NamedChunksPlugin
NamedModulesPlugin

entry

既然是模块化开发，就需要有一个入口文件，相关的模块就可以根据这个入口文件形成一个树形的依赖关系。

当然 webpack 还没有智能到可以自动识别出你的模块依赖关系，所以需要咱们来告诉它，如果你不告诉它，则会默认把 src/index.js(webpack4.x+) 当做入口文件。

入口文件可以是一个文件(string)：

// webpack.config.js

module.exports = {

  entry: 'src/main.js'

}

也可以是多个文件(array)：

// webpack.config.js

module.exports = {

  entry: ['src/login.js', 'src/logout.js']

}

甚至也可以是一个对象(object)：

// webpack.config.js

module.exports = {

  entry: {

    login: 'src/login.js',

    logout: 'src/logout.js',

  }

}

这三种写法的区别是：

传入一个文件(string)的时候，会把所有具有依赖关系的模块打包生成一个文件;
传入多个文件(array)的时候，还是会打包生成一个文件，webpack 会把这些文件合并在一起，但是执行的时候会按照数组内文件的顺序依次执行;
传入对象的时候，则会根据对象key的个数，打包出对应数量的文件;

很显然，传入对象的方式更复杂，但也更利于扩展，同时也适合用来打包多页应用。

output

有进必有出，webpack 也需要我们指定打包后的文件存放位置，也叫做出口文件，和 entry 一样，output 也有默认值 dist/main.js(webpack4.x+) 。

下面是 output 常见的配置项：

// webpack.config.js

module.exports = {

  output: {

    path: __dirname + '/dist',

    filename: '[name].bundle.js',

    publicPath: '/assets/'

  }

}

path

指定打包后的文件存放位置，注意这是一个 绝对路径 ！上面的例子中用了 node 内置的常量 __dirname ，该常量表示当前执行文件所在的目录，所以我们打包出的文件就存放在和 webpack 配置文件同级的 dist 目录下面。

filename

打包后的文件名称，该选项有5个可配置项：

配置项	作用
[name]	模块名称，对应 entry 中的 key 值，如果 entry 传入的是 string 或 array 默认为 main
[id]	模块id，由 webpack 生成
[hash]	模块的 hash 值，当有文件修改时，这个值就会重新计算并改变
[chunkhash]	这也是一个 hash 值，webpack中每打包生成一个文件，就叫一个chunk ，它是 chunk 本身的 hash ，通常用它来做文件缓存

补充一个小知识，如果 entry 中传入的是对象，且对象的 key 值像这种形式 "a/b" ，并且在 output.filename 中设置了 [name] 那么打包出的文件会存放在 a 文件夹下的 b.js 中（a/b.js）。

publicPath

关于这个配置，笔者曾经纠结了好久，知道它的作用，却总是无法理解，在网上看了很多关于 publicPath 的介绍，包括 webpack 的官网，但一直没有豁然开朗的感觉，直到后来在自己的项目中遇到了一些问题，才算是明白了为什么会有这个选项。

如果不想看下面这些内容，可以直接查看总结，建议第一次阅读的时候跳过下面这一小段，等到了 devServer.publicPath 再回过来看一遍。

这里我们可以反向的分析一下。首先，在设置了 path 和 filename 这两个属性之后，便可以确定打包出的文件在本机存放的具体路径了。然后需要明确一点，打包出的代码需要上传到 Web 服务器上，这些文件中可能有 .css .js .png 等等，它们最终都要以 .html 为载体，假设这个文件是 index.html 就像这样：

注意：index.html 是通过 html-webpack-plugin 插件生成的，下文会介绍到。

<!DOCTYPE html>

<html lang="en">

<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <meta http-equiv="X-UA-Compatible" content="ie=edge">

  <title>webpack</title>

  <link href="index.css" rel="stylesheet">

</head>

<body>

  <img src="hello.png" />

  <script type="text/javascript" src="index.bundle.js"></script>

</body>

</html>

从这段简单的 html 中我们可以得到一个信息，那就是 index.css、 hello.png、 index.bundle.js 这个三个文件都放在相对于 index.html 的同一级别下面，就像这样：

dist

├── index.html

├── hello.png

├── index.css

└── index.bundle.js

如果我们的 webpack 设置是下面这样的：

// webpack.config.js

module.exports = {

  entry: {

    app: './src/main.js',

  },

  output: {

    path: __dirname + '/dist',

    filename: '[name].bundle.js'

  }

}

那么打包出来的文件结构应该是和上面的一模一样的，我们按照这个结构上传到 Web 服务器，不需要修改什么就可以直接访问了。

一般公司都有专门的 cdn 服务器，那么你可以把 index.css、 hello.png、 index.bundle.js 这些资源传到 cdn 服务器上，假设你 cdn 地址是 https://mycdn.com 那么你可以通过 https://mycdn.com/index.css 的方式来访问相应的资源。这时候为了使我们的网站不报错，我们就需要将 index.html 中的资源引用方式改为：

<link href="https://mycdn.com/index.css" rel="stylesheet">

<img src="https://mycdn.com/hello.png" />

<script type="text/javascript" src="https://mycdn.com/index.bundle.js"></script>

很明显，这种打包完成后还需要手动修改的方式很智障，而如果我们不想做这样修改的话，只需要将 output.publicPath 设置为 https://mycdn.com/ ，便会在打包出来的 index.html 文件内自动加上 output.publicPath 设置的值。

还有一种情况，就是笔者所遇到的情况了。假设你的项目还是传统的开发方式，并没有采用前后端分离，用的还是后端模板的方式。而你作为一个前端开发，你想要模块化开发所以引入了 webpack 来打包，后端的哥们跟你说，你把你打包出的文件放在咱们项目的 static 文件夹下面就行了。一开始都没什么问题，但是在做某一个功能的时候，你发现打包出来的文件体积有点大，而且有些代码可以通过按需加载的方式拆分一下，这时候你想到了用 import() 来动态加载，于是除了打包出了 index.js ，还有一些需要动态加载的 .js 文件，你把它们都放进了 static 下面。但是在调试的时候却发现，那些需要按需加载的资源无法加载了，全都是 404 ，咦？怎么回事小老弟！打开控制台看一下，所有 404 的资源地址都是 https://test.com/assets/xxx.js 。干！说好的 static 怎么变成了 /assets/ 了？后端的哥们跟你说，这是后端框架的原因，虽然你是放在 static 下面，但是请求的时候请求的是 相对于当前页面的 /assets/ 这个路径 ，总之 后端没法改，需要前端想办法解决。这个时候，我们只要把 output.publicPath 设置为 /assets/ 就可以解决这个问题了。

总结：

这个选项默认是 '' ，一般情况是不需要修改的。但是在有些情况下，打包出的资源部署上线后，可能会出现 404 访问不到的情况。这个时候就需要配置一下这个选项来解决这个问题了。

如果你将打包后的资源上传到 cdn 上面，那么需要将它设置为可以通过 cdn 方式访问的地址，比如 publicPath: 'https://mycdn.com/assets/' ；

如果你的项目在服务器上面目录结构和你打包出的文件结构不一样，比如你打包出来的 .html 和 .js 是平级的，但是在服务器上却把 .js 文件都放在 /assets 下面，那你需要设置为 publicPath: /assets/' 。

所以这个值并不会影响你打包出的文件路径，它只是用来设置在线上运行的时候，所请求的资源相对于服务 /html页面的路径。

简单的说，在线上运行的时候，所请求的资源具体路径是 https://你的域名/publicPath/资源 或者 https://你设置的cdn地址/资源 。

output 的常用配置项就这三个，如果你想用 webpack 把你的代码打包成类库，你还需要配置一下 output.library 、 output.libraryTarget 等，不过笔者建议直接使用 rollup 打包类库。

所以如果有下面这样一份 webpack 配置文件：

// webpack.config.js

module.exports = {

  entry: {

    app: './src/main.js',

  },

  output: {

    path: __dirname + '/dist',

    filename: '[name].bundle.js'

  }

}

会打包出如下这些文件：

project

├── src // 源代码文件夹

│   ├── main.js

│   ├── login.js

│   └── logout.js

├── dist // 打包后生成的文件夹

│   └── app.bundle.js

└── webpack.config.js  // webpack 位置文件

总结：本篇介绍了前端模块化的发展历史和如何使用 webpack 打包实现模块化，那么在打包过程中 webpack 是如何多不同的文件进行解析、编译、处理的呢？在写一篇中将会详细的介绍。