前引
Webpack 在截稿时，已经开发刀3.4.1，从2014年1月20发布第一版至此，已然3-4个年头，Evan 曾说，想要深刻了解一个框架，那么就从他的最初版本研究就行了。
说到底 Webpack 是为了 JavaScript 打包而生。打包过程中，Webpack 会根据项目的引用声明生成一个依赖图，随后将项目代码封装为几个不同的 bundle（可以理解为容器）浏览器会根据指示加载这些容器并执行。
你可以高度定制你的打包过程，显然，这本身就属于高级部分了。Webpack 未来的没落应该会源于此处：向初级使用者提供方便的一键完成功能，向高级使用者提供可定制属性，才是成功之道。
核心概念
既然是可配置，剩下的就要知道可以配置哪些东西。类似于一份说明书，更像PLC，让你亲自写一个打包工具出来。
说到概念，这里与官网就有些不同了。入口、出口、参数、加载器这些属于配置项，而，配置语法，模块，模块解析，依赖图谱这些未出现在配置文件中的才属于概念部分。
入口
Webpack 创造了一个项目依赖图谱。图谱成树状，树根就被称为入口。
加载器
对于创造出来的这棵树中的每一个节点都是我们处理后才挂上去的，所以提前要告诉Webpack 如何去处理他们。Webpack 只认识 JavaScript，所以你需要使用加载器（预处理器）来将其他文件打包为 JavaScript Module，如此一来，Webpack 就像处理普通文件一样处理他们了。
插件
一种预处理器只能处理一种文件，甚至于集中处理器才能处理一种文件，所以需要更加强大通用的处理器完成复杂的工作，于是插件应运而生，插件会在加载器处理之后，以 compilation 或者 chunk 为对象进行进一步处理。遗憾的是，这里并未实现依赖注入，只能手动去实例化插件，并传入配置项让插件生效。
出口
Webpack 将项目代码处理完成后，尚不知应该怎么处理这些代码，所以你应该告诉他放在哪里，起个什么名字
入口
入口就是容器的瓶盖，
语法
配置入口有两种形式
entry: string|Array<string>
entry: {[entryChunkName: string]: string|Array<string>}
entry 后边直接跟入口文件地址是一种语法糖，等价于
entry: {
main: './path/to/my/entry/file.js'
}
entry: {
main: ['./path/to/my/entry/file1.js', './path/to/my/entry/file2.js']
}
当传递一个数组进入一个入口时，即可将多个入口文件封装到一个chunk中。
实际开发中，第二种情况用的更多些
应用场景
将业务代码与第三方依赖分开打包
由于有了 DllPlugin，所以这种初级阶段的分离打包的形式已经被逐步淘汰，此处仅作说明使用。
entry: {
app: './src/app.js',
vendors: './src/vendors.js'
}
此时，相当于创建了两个容器，并给了两个瓶盖，每一个瓶子上都有使用说明（Webpack 的启动文件）
多页面应用中抽离公共代码
不同的业务主页面中或许有许多相同的样式和 JavaScript 共用部分，通过 Webpack 打包的方式将其提取出来，减少网络请求数量。
entry: {
pageOne: './src/pageOne/index.js',
pageTwo: './src/pageTwo/index.js',
pageThree: './src/pageThree/index.js'
}
new commonsChunkPlugin({
name: 'vendor',
minChunk: 2
})
此处需要 Plugin-CommonsChunkPlugin 的帮助，来实现提取。
输出
输出的主要用处是告诉 Webpack 如何将生成的文件写到磁盘中，需要注意的是，虽然有很多瓶可乐，但只能让我一个喝（出口只能有一个）
语法
至少有两个配置项，一个是名字，一个是绝对地址，这里通常使用 Path 库来帮忙
output: {
filename: 'bundle.js',
path: '/home/proj/public/assets'
}
当配置了多个入口时，就需要使用预置名的正则来区分不同的输出文件名
output: {
filename: '[name].js',
path: __dirname + '/dist'
}
其中[name]就是刚提到的预置名，常见的还有[hash:10]等。另外，根据场景的不同，输出中还有些其他的属性可以配置。
使用场景
配置 CDN 发布目录
output: {
path: "/home/proj/cdn/assets/[hash:5]",
publicPath: "http://cdn.example.com/assets/[hash:10]/"
}
前者是本地打包使用，后者为发布时在 index.html 中插入的 CDN 地址，当然，需要手动上传 CDN。
预处理器
预处理器或者叫做加载器是用于源码或者源文件处理的。这些预处理在你依赖某个包的时候就对这个包进行了预处理，所以加载器跟gulp-task 很像了。可惜的是你得知道哪些文件有哪些常用的稳定的加载器，毕竟加载器是个开放的生态，很多人自定义了些加载器，鱼龙混杂，甄别这玩意也是个头疼的事儿。
为了解决这个问题，官方给了些推荐。
语法
加载器安装成功后，即可拿来使用了。需要注意的是
- 加载器被定义在 module > rules中
- 使用正则选取要处理的文件后缀进行处理
module: {
rules: [
{ test: /\.css$/, use: 'css-loader' },
{ test: /\.ts$/, use: 'ts-loader' }
]
}
其中，use :'some-loader'是语法糖。需要向某个 loader 配置参数时，需要使用完整写法。
{
test: /\.css$/,
use: [
{ loader: 'style-loader' },
{
loader: 'css-loader
options: { modules: true }
}
] }
还要两种使用加载器的方式，不过非常不推荐了。
- 行内使用，在 import 时，以参数的形式输入
import Style from 'style-loader!css-loader?modules!./styles.css'这种方式会覆盖 webpack.json 中的配置 - 命令行使用，在运行 Webpack 的时候，可以以--some-loader 的形式使用
插件
插件与预加载器相同，做些“额外的”事儿。Webpack 本身就是构建在插件之上，当你不会处理某个场景时，完全可以看一下 Webpack 源码。
原理
如果有面试官问你做没做过 Webpack 插件，你可以大大方方的说做过，因为做插件太简单了。
插件本身就是一个函数类，函数的apply属性会被 Webpack 的编译器调用到。将 Webpack 中的半成品代码拿给插件使用，并要求插件将处理后的代码再返给编译器。
function IamAFuckingPlugin(){}
IamAFuckingPlugin.prototype.apply = (compiler){
compiler.plugin('run', (compiler, cb)=>{
console.log('do plugins things here');
cb();
})
}
语法
使用 plugin 与使用 loader 也有几分相似，不过 plugins 是独立到 module 之外的。
plugins: Array<Plugins Objects>
Webpack 配置文件
你可能注意到了，绝大多数 Webpack 的配置文件结构相似度很高。说到底，这就是一个 CommonJs 的文件。你可以在这个文件中使用Nodejs 的开发技术对配置进行灵活控制。甚至可以通过函数的方式生成部分配置。
模块
在模块化开发的风潮中，开发者将程序分拆为不同的块，并将这些块称为模块。以便于分开维护和复用。好的模块设计高内聚低耦合，甚至趋向于一致性。这些一致性就成就了 Webpack 这种打包工具，将最佳实践中外置接口做成工具的输出内容。用于封装用户的业务内容。
Webpack 支持各种语言的各种形式的模块化组织形式。
模块解析
模块解析器主要 用于解析项目依赖所在的路径。手动配置的场景用于处理那些不能自动解析的模块。最常见用于解决那些需要从 node_modules 里找到源码并多次引用的。
Webpack 使用enhanced-resolve 来解析三种不同的引用方式。
- 绝对路径引用
- 相对路径引用
- 模块路径
