前端工程化---webpack的编译优化

我们知道 webpack在Compiler和Compilation的各个生命周期中，对Compiler实例来讲消耗时间最长的是生成编译过程实例后的make阶段,在这个阶段，会去执行模块编译和优化的完整过程。

而对于Compilation的工作流程来说，不同项目和配置则各有不同。总体而言，它会在编译模块和后续优化见证的生成产物并压缩代码的过程中，都是比较耗时的。

不同项目的构建，在整个流程的前期初始化阶段与最后的产物生成阶段，构建时间区别不大，而真正影响整个构建效率的还是在compilation实例的处理过程中。

这一过程又可以分为两个阶段来看，成为编译模块的阶段和优化打包处理这个阶段。

编译模块阶段所耗的时间，是从单个入口点开始编译每个模块的时间总和。要提升这一阶段的构建效率，大致可以分为三个方向。

• 第一个方向，可以尝试去减少执行编译模块，如果编译参与编译的模块减少之后，那后续流程也会相应的减少，能提升一个编译构建的这个效率。
• 第二个方向是可以提升单个模块的构建速度，从而达到对整个过程的这个提速。
• 第三个是可以尝试并行构建来提升总体的效率。

减少执行构建的模块，显而易见，如果一个项目每次构建都需要编译1000个模块，但是通过分析后发现最后有500个模块不需要编，那显而易见，经过优化后构建效率会大幅提升。

前提是要能找到那些原本就不需要进行构建的模块。

在实际的操作中，我们可以使用 ignorePlugin插件，比如我们经常使用的 moment这个时间包，默认情况下，它会附带多国语言包，但是我们只需要使用本国语言。

Webpack的ignorePlugin插件可以在构建模块时直接剔除掉那些需要被排除的模块，从而提升构建模块的速度，减少产物体积。

new webpack.IgnorePlugin({
  resourceRegExp:/^./locales$/,
  contextRegExp:/moment$/
})

第二种方案是按需引入依赖库的相关模块。，例如我们常用的lodash这个依赖包，这个包在构建过程中，在项目里我们可能只会用它的少数几个方法，但是在构建时我们会发现，整个依赖包都被打进来了，导致他在扩建和后期处理过程都比较耗时。

要解决这个问题，最佳的方法是在导入声明时只导入依赖包内的特定模块，这样就可以减少固定时间和产物的体积。

除了导入式声明特定的模块外，它可以使用插件babelPluginLodash或者是babel-import-plugin插件来达到相同效果。

第三个方案是这个使用DLL的plugin 它的核心思想是将项目所依赖的框架的模块单独的去构建打包，与普通的构建流程区分开。

例如原先一个依赖react和react的文件，在构建时我们一般会像下面那样去处理他，整个这个构建编译的过程都会很长。

而通过dll-plugin和dll-reference-plugin之后，那这个正常的这个固定时间就变成像下面那样，引入模块是瞬间完成构建效率瞬间提升10倍，因为我们减少了那个固定时最耗时的模块。

第四种方案是使用在webpack配置中使用External。External更简单，External在配置中不包含依赖框架生成方式，所以这种情况下，通常我们是需要使用CDN的依赖包在页面上直接去引用这个，external配置的依赖包需要单独指定依赖模块下载方式，比如使用全局对象、commonJS、AMD 等。

经过External的配置后，构建速度也有很大的提升面。

而提升单个模块的构建速度优化方方式主要有下面几种：

第一种是使用include、exclude，webpack加载器中有include和exclude配置常用的优化特定模块构建速度的方式之一。

include和exclude这两个配置参数作用就比较简单。Include的作用是对只对符合条件的模块来进行使用，指定load来进行转入处理，而exclude则相反，是对指定条件的模块不使用该loader。

第二种是如果loader中的include与exclude配置存在冲突的情况下，一个loader里面既写了include又写了exclude，这种情况下会优先使用exclude的配置，而忽略冲突的include部分的配置。

第三种就是根据我们的项目环境选择是否开启 SourceMa。

第四种就是针对 TS 的优化。ts 可以使用 ts-loader,也可以使用 Babel-loader。但是，ts-loader默认在编译前会进行类型检查，因此导致编译速度较慢，因此，我们可以在使用ts-loader时，加上transpileOnly:true让它在编译时忽略类型检查，从而提升编译效率。

第五种是resolve的配置，指定的是在构建时指定查找模块文件的规则，比如resolve.models查找模块的目录范围，Resolve.extensions就是查找文件类型范，resolve.mainField, 去查找对应模块的package.json中的主文件的属性名点，这些规则在处理每个模块时都会用到。

尽管对于小型项目来说，这几个选项对于构建速度影响其实不大，但是对于大型的模块众多的项目来说，有的项目总共打包下来，他的所处理模块可能有几千个甚至上万，这种情况下，这种配置的变化就可能产生可观的构建时长的区别。

第三个优化的方向，也在编译阶段提交的方向去使用并行方式来提升构建效率。

对于大型项目来说，大型项目的生产构建过程中，这些工具仍然有发挥作用空间。比如：HapppyPack , thread-loader。