为了避免一次加载过大的文件和充分利用浏览器缓存,我们需要将不经常被修改的文件单独打包。即对项目中的代码进行分割。webpack支持两种代码分割的方式。
1.同步引入文件
index.js代码:
import _ from 'lodash';
console.log(_.join(['Hello', 'webpack'], ' '));
如果直接打包index.js会发现业务代码和loadsh库打包到了一个bundle.js文件中。可见webpack默认不会处理同步引入的文件。此时修改webpack的配置,增加optimization.splitChunks的配置项:
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
module.exports = {
mode: 'development',
entry: {
index: './src/index.js'
},
output: {
filename: 'bundle.js',
chunkFilename: '[name].bundle.js',
path: path.resolve(__dirname, 'dist')
},
plugins: [
new CleanWebpackPlugin(),
new HtmlWebpackPlugin()
],
optimization: {
splitChunks: {
chunks: 'all'
}
}
}
再次打包发现除了bundle.js文件还生成了vendors~index.bundle.js。我们成功的将lodash分割了出来。
2.异步引入文件
修改index.js代码:
function getComponent() {
return import(/* webpackChunkName: "lodash" */ 'lodash').then(({default: _}) => {
const element = document.createElement("div");
element.innerHTML = _.join(['Hello', 'webpack'], ' ');
return element;
}).catch(error => 'An error occurred while loading the component');
}
getComponent().then(component => {
document.body.appendChild(component);
})
删除掉webpack中optimization.splitChunks的配置项后再进行打包,结果和上面的一致。loadsh被提取到了vendors~lodash.bundle.js文件中。所以webpack默认是仅对异步加载的块进行分割。我们需要default的原因是,由于Webpack4在导入CommonJS模块时,导入将不再解析为module.exports的值,而是为CommonJS模块创建一个人工命名空间对象。
我们还可以用async函数对上面的代码进行简化:
async function getComponent() {
const {default: _} = await import(/* webpackChunkName: "lodash" */ 'lodash');
const element = document.createElement("div");
element.innerHTML = _.join(['Hello', 'webpack'], ' ');
return element;
}
getComponent().then(component => {
document.body.appendChild(component);
})
打包结果同样将lodash分割了出来。
但是不管是同步引入模块还是异步引入都会受splitChunks配置项的影响(例如分割出的lodash名称为vendors~lodash.bundle.js)。下面我们来详细的说一下webpack中splitChunks默认配置:
module.exports = {
optimization: {
splitChunks: {
chunks: 'async',//表示将选择哪些块进行优化。提供字符串时,有效值为all、async和initial,默认是仅对异步加载的块进行分割。
minSize: 30000,//模块大于minSize时才会被分割出来。
maxSize: 0,//生成的块的最大大小,如果超过了这个限制,大块会被拆分成多个小块。
minChunks: 1,//拆分前必须共享模块的最小块数。
maxAsyncRequests: 5,//按需加载时并行请求的最大数目。
maxInitialRequests: 3,//入口点的最大并行请求数
automaticNameDelimiter: '~',//默认情况下,webpack将使用块的来源和名称(例如vendors~main.js)生成名称。此选项允许您指定要用于生成的名称的分隔符。
automaticNameMaxLength: 30,//允许为SplitChunksPlugin生成的块名称的最大长度
cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/,//控制此缓存组选择的模块。省略它将选择所有模块。它可以匹配绝对模块资源路径或块名称。匹配块名称时,将选择块中的所有模块。
priority: -10//一个模块可以属于多个缓存组,模块出现在优先级最高的缓存组中
},
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true//如果当前块包含已经从主包中分离出来的模块,那么该模块将被重用,而不是生成新的模块
}
}
}
}
};
这些配置共同控制打包流程,例如还是之前同步引入lodash的例子
index.js
import _ from 'lodash';
console.log(_.join(['Hello', 'webpack'], ' '));
修改webpack的配置:
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendors: false,
default: false
}
}
}
再次打包发现lodash并没有被分割出来,chunks虽然设置成了'all',但是webpack还会继续查看cacheGroups中的配置,发现都为false,webpack就不知道要把lodash打包到哪里,导致分割失败。
那么继续修改下配置:
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/,
priority: -10
},
default: false
}
}
}
再次打包,因为lodash是属于node_modules模块的,所以lodash被提取到了vendors~index.bundle.js文件中,代表来源于vendors缓存组并且是从index.js模块分割出来的。
继续修改配置:
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendors: false,
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true
}
}
}
}
再次打包发现lodash并没有被分割出来,default不应该是默认匹配所有的么,仔细查看配置发现minChunks默认为2,意思是lodash至少需要被引用两次才会被分割出来,我们的代码中lodash只被index.js引用了一次。所以我们修改minChunks为1,再次打包,lodash被打包到了default~index.bundle.js文件中。说明此时被匹配到了default缓存组里面。如果一个模块被同时匹配到了多个缓存组,就要根据priority来决定模块被分配到哪个缓存组了,priority越大优先级越高。所以代码分隔是受splitChunks多个配置项共同控制的。
vue-cli3对cacheGroups的初始配置(@vue\cli-service\lib\config\prod.js)为:
webpackConfig
.optimization.splitChunks({
cacheGroups: {
vendors: {
name: `chunk-vendors`,
test: /[\\/]node_modules[\\/]/,
priority: -10,
chunks: 'initial'
},
common: {
name: `chunk-common`,
minChunks: 2,
priority: -20,
chunks: 'initial',
reuseExistingChunk: true
}
}
})
在我们的项目中要引入很多的第三方组件库例如element-ui,还有公司内部的一些组件库,如果我们使用默认配置不做任何修改,vendors缓存组中的内容会很多,页面引用时耗时就会较长,所以将缓存组中的内容进行拆分是很有必要的。
例如我们将element-ui分割成一个独立的chunk,cacheGroups中配置如下:
cacheGroups: {
elementUI: {
priority: 20,
name: "element-ui",
test: /element-ui/,
reuseExistingChunk: true
},
vendors: {
chunks: 'all',
test: /[\\/]node_modules[\\/]/,
priority: 0,
minChunks: 2,
name: 'vendors',
reuseExistingChunk: true
}
}
elementUI缓存组的test我直接用的模块名称,至于为什么不是:
test: /[\\/]node_modules[\\/]element-ui[\\/]/
是因为项目如果是用npm install安装的没有问题,element-ui可以被分割出来。但是假如是用cnpm install安装的,安装完的element-ui模块名称为_element-ui@版本号@element-ui,就不能匹配到elementUI缓存组中了,使用模块名称可以兼容两种安装方式。
再说一下optimization.runtimeChunk它的配置很简单:
config.optimization.runtimeChunk = {
name:'manifest'
};
作用却很大,它是将包含chunks 映射关系的 list单独从 app.js里提取出来,因为每一个 chunk 的 id 基本都是基于内容 hash 出来的,所以你每次改动都会影响它,如果不将它提取出来的话,等于app.js每次都会改变。缓存就失效了。
如果要分析自己项目中的打包结果,可以使用webpack-bundle-analyzer插件,来对大的包或者app.js进行优化。