webpack实战——资源输入与输出
webpack实战——资源输入与输出
写在前面
这是webpack实战系列笔记的第三篇记录：资源输入与输出。前两篇：
•打包第一个应用•模块化与模块打包
1. 资源处理流程
前两篇的博客中提及，webpack主要作用是对 解决模块之间的依赖，把各个模块按照特定的规则和顺序组织在一起，那么我们就要对资源处理的流程有一个了解。各个流程如下：
处理流程
1.指定入口(entry)：告诉webpack从哪儿入手开始打包。2.打包封装(chunk)：存在依赖关系的模块在打包时被封装为一个chunk，chunk就像文件袋，里面包裹着很多文件（模块）。根据配置，可能会产生一个或者多个chunk。3.打包产物(bundle)：由上述chunk得到的打包产物则为bundle。
三者关系如下
三者关系图
2. 资源入口
webpack决定入口文件路径需要通过两个配置项：context和entry。配置时做了两件事：
•确定入口模块位置 告诉webpack从哪儿开始打包•定义chunk name 分两种情况，如果是单入口，那么默认chunk name是“main”，如果是多个入口，则需要为每个入口定义不同的chunk name来作为chunk的唯一标识。
2.1 context
context可以理解为资源入口的路径前缀，要求使用绝对路径的形式。以下两个案例效果相同：
注：入口文件为: ./src/js/index.js
// 案例1const path = require('path')
module.exports = { // 入口 context: path.join(__dirname, './src'), entry: './js/index.js', // 出口 output: { filename: 'bundle.js' }, // 打包模式：develop-开发，production-生产 mode: 'development',}
// 案例2const path = require('path')
module.exports = { ... context: path.join(__dirname, './src/js'), entry: './index.js', ...}如果存在多入口情况，使用context则可以使得入口编写更加整洁。如果忽略不写，那么默认值为当前工程的根目录。
2.2 entry
在上面可以看到，entry指定确定的入口文件。而entry的写法则有多种，如：字符串、数组、对象、函数，那么根据不同的场景来选择使用即可。
注：假设入口文件为: ./src/index.js
2.2.1 字符串类型
module.exports = { entry: './src/index.js',
output: { filename: 'bundle.js' }, mode: 'development',}2.2.2 数组类型
module.exports = { entry: ['babel-polyfill', './src/index.js']}
// 上面配置等同于↓// webpack.config.jsmodule.exports = { entry: './src/index.js'}// src/index.jsimport 'babel-polyfill'...2.2.3 对象类型
module.exports = { entry: { index: './src/index.js', main: './src/main.js' }}其实对象类型是为定义多入口而设计的。如果资源入口有多个则必须使用对象类型来配置，其中，配置的属性名是chunk name，其对应的value值则是入口路径。如上述例子，main这条配置：chunk name为main,入口路径是 ./src/main.js。
2.2.4 函数类型
函数类型的话可以返回上述介绍的三种类型的任意类型。如：
// 返回字符串类型module.exports = { entry: () => './src/index.js'}
// 返回对象类型module.exports = { entry: () => ({ // 返回对象类型，其中value的路径地址可以是数组类型 index: ['babel-polyfill', './src/index.js'], main: './src/main.js' })}2.3 实例
我们现在应用前端一些主流框架来构建项目时，可能会发现我们构造出来的页面属于单页面应用（SPA：single page APP）。那么对于单页面应用来说，一般只需要定义一个入口即可，如：
module.exports = { entry: './src/app.js'}然后所有的库、模块等，均由该入口文件进行引用。此法其实利弊分明：
•一方面只会产生一个JS文件，依赖关系清晰•另一方面则是项目过大时会造成资源体积包过大，降低页面渲染速度，从而影响用户体验度
为解决该问题，我们使用提取vendor的方法。
vendor
vendor，小贩; 摊贩; 供应商。
在webpack中，vendor则指的是工程中用到的库、框架等第三方模块打包而产生的bundle。如：
const path = require('path');
module.exports = { context: path.join(__dirname, './src'), entry: { app: './app.js', vendor: ['react', 'react-dom', 'react-router'] }}可以看到，app和以往一样无需改动，但我们新增了一个chunk name为 vendor的入口，通过数组形式放入了一些第三方模块。
但我们并没有设置vendor的入口路径，webpack如何去打包呢？此时我们可以采用optimization.splitChunks来将app和rendor这两个chunk中的公共模块给提取出来，然后app.js中只包含业务模块，第三方模块依赖都被抽取出来作为新的bundle。由于被抽取的模块不常变动，也可以利用这个特性来做客户端缓存，从而加快整体的渲染速度。
多入口
刚才说了单页面应用，那么多页应用一般有多个入口，在此场景中，为了尽可能减小资源的体积，我们则是希望每个页面加载自身必要的逻辑，而不是都打包到一个bundle中。此时，就需要多入口配置来实现：
const path = require('path')
module.exports = { context: path.join(__dirname, './src'), entry: { page1: './page1.js', page2: './page2.js', page3: './page3.js' }}在上面配置中，入口与页面一一对应，如此的话每个html则只需要引入各自的js就可以加载其所需的模块。
另外，对于多页应用的场景，我们同样使用 vendor，将各个页面间的公共模块进行打包。如下：
const path = require('path')
module.exports = { context: path.join(__dirname, './src'), entry: { page1: './page1.js', page2: './page2.js', page3: './page3.js', vendor: ['react', 'react-dom'] }}这样配置后，加上配置optimization.splitChunks将react和react-dom从各个页面中提取出来，生成单独的bundle即可。
3. 资源出口
资源出口配置都集中在output对象中，包含了几十个配置项，但是大多数无需刻意配置，我们常用的一般有filename、path和publicPath。
3.1 filename
filename，控制输出资源的文件名，值为字符串形式。如：
module.exports = { // 入口在 ./src/js/index.js entry: './src/js/index.js',
output: { filename: 'bundle.js' // 字符串形式，控制输出资源的名字 }}虽说值为字符串形式，但是字符串中可以不仅仅是文件名，还可以加上路径，如：
module.exports = { // 入口在： ./src/js/index.js entry: './src/js/index.js',
output: { filename: './js/bundle.js' // 则会自动在dist下创建js目录，bundle会打包在js目录下 }}执行打包操作后，可以看到在dist目录下生成了一个js目录，将bundle资源放在了js下：
可指定路径输出
那么如果是多入口场景，我们则需要为每个bundle指定不同的名字避免命名冲突。这时我们可以试用webpack提供的一种类似模板语言的形式动态生成，如：
module.exports = { entry: { index: './src/index.js', app: './src/app.js' },
output: { filename: [name].js' // [name]类似模板语言 }}执行打包命令后生成的资源：
[name].js
从上图打包结果可以看出，我们配置的[name]在资源输出时，会被替换为 chunk name，最后打包输出的资源分别是app.js和index.js。除了[name]之外，还有几个常用的配置：
名称 | 描述 |
|---|---|
[hash] | webpack此次打包所有资源生成的hash值 |
[chunkhash] | 当前chunk的hash |
[id] | 当前chunk的id |
[query] | filename配置项中的query |
在这几个变量中，
[name]、[id]和[chunkhash]在有多个chunk时可以使用，用来对chunk进行区分。另外一个比较好的效果控制缓存：[hash]和[chunkhash]都与chunk内容直接相关，当chunk内容改变时，可以同时引起资源文件名的改变，从而导致用户在下一次请求资源文件时会下载新版本的内容而不是用本地缓存。如果要控制客户端缓存，一般加上[chunkhash]，因为每个chunk所产生的chunkhash只与自身内容相关，不会影响到其他资源，可以精准的让客户端缓存得到更新。
在生产环境中，我们可以如下配置filename：
module.exports = { entry: { index: './src/index.js', app: './src/app.js', },
output: { filename: '[name]@[chunkhash].js' }}3.2 path
path指定输出资源的位置，值必须是绝对路径，如：
const path = require('path');
module.exports = { entry: './src/index.js', output: { filename: 'bundle.js', path: path.join(__dirname, 'dist') }}注：在webpack4版本及之后版本，output.path的默认路径就是dist，如果我们需要更改则如上配置可修改，如无需修改则不需单独配置。
3.3 publicPath
publicPath相对于path还是比较容易混淆的。
•path：指定输出资源的输出位置•publicPath：指定资源的请求位置
那么怎么理解输出位置和请求位置呢？
•输出位置：
打包后资源产生的目录，不自定义配置的话默认是dist目录•请求位置：JS或者CSS所请求的间接资源路径。页面中的资源分两种：一种是由HTML页面直接请求的，比如通过script标签加载的JS；另一种是由JS或者CSS请求的，比如异步JS、CSS请求的图片字体等。publicPath就是用来指定这部分间接资源请求位置的。
webpack-dev-server
第一篇得时候介绍过关于webpack-dev-server。在webpack-dev-server中，也配置了一个publicPath，作用是指定webpack-dev-server的静态资源服务路径。如：
module.exports = { ...
devServer: { publicPath: '/assets/', // 指定webpack-dev-server的静态资源服务路径 port: 8088 }}4. 实例
4.1 单入口
单入口场景，通常不必设置动态的filename，直接输出文件名即可：
const path = require('path');
module.exports = { entry: './src/index.js',
output: { filename: 'bundie.js' },
// 如果需要使用webpack-dev-server，那么则配置devServer的publicPath即可 devServer: { publicPath: '/dist/' }}4.2 多入口
多入口场景，则需要使用模板来配置filaneme，如：
const path = require('path');
module.exports = { entry: { index: './src/index.js', app: './src/app.js', },
output: { filename: '[name]@[chunkhash].js' },
// 需要devServer的话添加即可 devServer: { publicPath: '/dist/' }}5. 小结
本篇主要记录的是webpack打包控制资源的输入和输出流程，以及各自的一些常用配置，如entry、context、filename、path等。除此之外，还介绍了例如vendor方法来提取公共资源，更有效的利用缓存来提升页面渲染速度。下一篇简述“一切皆模块”的思想。
精彩推荐
webpack实战——打包第一个应用
常用验证码之滑动验证码|图形验证码