今天我们先说一下文webpack中的Tree Shaking:
为什么需要使用Tree shaking?
当我们在使用webpack进行模块打包时,如果就仅仅是我们之前的一些基础的配置项,最终会发现我们打包出的所有的模块仅仅只是一个bundle.js文件,webpack将我们所有的打包的模块都放到了这个文件中,就会使得bundle.js文件变得特别的大,这还不是最关键的。当我们在打包时,我们经常会引入一些外部的库来使用,比如lodash等等,但是实际我们在使用时仅仅只是使用的其中的极少数的方法,那么我们就会考虑,是否可以对一些库文件中没有使用到的内容不进行打包,只打包我们使用到的可不可以呢?这是肯定的,今天我们说到的这个Tree Shaking就是解决这个问题的。
** Tree shaking使用:**
配置使用Tree Shaking我们只需要在webpack的配置文件中加入optimization配置项即可:
// ...
optimization: {
usedExports: true
}
//...
- 这里我们需要注意的是,使用Tree Shaking时处理的模块仅能够是使用es module引入的模块方可以进行。但是当一些模块我们不需要进行Tree Shaking时,我们也可以进行一些简单的配置后解决:在package.json配置文件中添加配置项:
"sideEffects": []
sideEffects配置项的参数为一数组,数组中指定的项就是我们不需要进行Tree Shaking的模块
当然在说完Tree Shaking 后,我们还要说一下的就是Split Code
何为Split Code?
如其字面含义,Split Code就是代码拆分。目的就是将我们的bundle.js的一个大文件拆分成多个小的js文件,避免在我们页面首次加载时引入一些未使用到的内容,而导致首屏的加载时间变得很长,而我们之后也可以使用Lazy Load的方式去加载其他的文件来提高使用体验。
如何配置使用Split Code?
关于Split Code,我们同样也就是需要在optimization配置项中进行相关的配置即可:
//...
optimization: {
splitChunks: { // 对代码中引入的模块进行分割
chunks: "all" // chunks: "all" 的含义时对所有引入的模块均进行代码的分割
}
}
//....
- 这里我们只配置了一下splitChunks的一项,它其实是有很多的默认配置项的,我们这里也简单的说一下:
splitChunks: {
chunks: "all",
minSize: 30000,
maxSize: 0,
minChunks: 1,
maxAsyncRequests: 5,
maxInitialRequests: 3,
automaticNameDelimiter: "-",
cacheGroups: {
vendors: {
test: /[\\/]node_modules[\\/]/,
priority: -10
}
}
}
- chunks: (all) 表示的是对于不管是同步加载还是异步加载的模块都将进行代码的分割,它可以结合vendors参数对分割的模块进行一些设置
- minSize: 指定当加载的代码块的大小大于指定的字节数才会进行代码的拆分
- maxSize: 表示当代码块的大小超过了限定的值时尝试对代码块进行二次的拆分,最终保证代码块的大小不超过给定值
- minChunks: 指定当代码块被引入了多少次后才进行代码的拆分,默认引入一次即进行代码分割
- maxAsyncRequests: 指定当分割的代码块超过给定值后就不再进行分割
- maxInitiialRequests: 指定初始页面的代码拆分个数不能超过指定的个数
- automaticNameDelimiter: 指定拆分出的代码块的名字和文件名之间组成chunks的文件名的分割符
- vendors-> test: 指定文件需要是从指定的文目录中引入才会被进行代码的拆分
- vendors->priority: 打包的优先级,优先级越高时会被先被打包
webpack进行split Code的底层实际依赖于SplitChunksPlugins插件,大家如果对Split Code感兴趣的话可以去gitHub上查看一下该插件,对于大家理解split Code 应该有一定的帮助。
好了,今天我们的webpack之旅就先到这里了,之后我们再接着说。、。