webpack 那些概念

前引

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
entry: {[entryChunkName: string]: string|Array}

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

Webpack 配置文件

你可能注意到了，绝大多数 Webpack 的配置文件结构相似度很高。说到底，这就是一个 CommonJs 的文件。你可以在这个文件中使用Nodejs 的开发技术对配置进行灵活控制。甚至可以通过函数的方式生成部分配置。

模块

在模块化开发的风潮中，开发者将程序分拆为不同的块，并将这些块称为模块。以便于分开维护和复用。好的模块设计高内聚低耦合，甚至趋向于一致性。这些一致性就成就了 Webpack 这种打包工具，将最佳实践中外置接口做成工具的输出内容。用于封装用户的业务内容。
Webpack 支持各种语言的各种形式的模块化组织形式。

模块解析

模块解析器主要用于解析项目依赖所在的路径。手动配置的场景用于处理那些不能自动解析的模块。最常见用于解决那些需要从 node_modules 里找到源码并多次引用的。

Webpack 使用enhanced-resolve 来解析三种不同的引用方式。

绝对路径引用
相对路径引用
模块路径