30. 优化loader性能

进一步限制loader的应用范围

思路: 对于某些库,不是用loader

例如: babel-loader 可以转换es6或者更高版本的语法,尅是有些库就是用es5写的,不要转换,使用babel-laoder反而浪费了构建时间

lodash 就是这样的一个库

lodash 实在es5之前出现的库,使用的是es3的语法

通过module.rule.exclude或module.rule.include,排除或仅包含需要应用loader的场景

module.exports={
  module:{
    rules:[
      {test:/\.js$/,
       exclude:/lodash/,
       use:'babel-loader'
      }
    ]
  }
}

如果更暴力一点,甚至可以直接排除掉nodule_modules目录中的模块,或仅转换 src 目录的模块

module.exports={
  module:{
    rules:[
      {test:/\.js$/,
       exclude:/node_modules/,
       // include:/src/ ,  仅仅转换src下面的js文件
       use:'babel-loader'
      }
    ]
  }
}

这种做法是对loader范围的进一步限制,和noParse不冲突,想想看,为什么不冲突

缓存loader的结果

我们可以基于一种假设: 如果某个文件不变,经过相同的loade解析后,解析后的结果也不变

于是,我们可以将loader的解析结果保存下来,让后续的解析直接使用保存的结果

cache-loader 可以实现这样的功能

module.exports={
  module:{
    rules:[
      {test:/\.js$/,
       exclude:/node_modules/,
       // include:/src/ ,  仅仅转换src下面的js文件
       use:['cache-loader',...cssloader]
      }
    ]
  }
}

有趣的是,cache-loader放在最前面,却能决定后续的loader是否运行

实际上,loader运行过程中,还有一个过程,pitch

cache-loader 还可以实现各自定义的配置,具体方式见文档

为loader开启多线程

thread-loader 会开启一个线程池,线程池中有适量的线程

它会把后续的loader方法哦线程池中运行,以提高构建的效率

由于后续的loader会被放到新的线程中,所以,后续的loader不能

• 无法使用webpack api 生成文件
• 无法使用自定义的 plugin api,
• 无法方位webpack option

  在实际开发中,可以进行测试,来决定 thread-loader 放在什么位置

特别注意: 开启和管理线程需要消耗时间,在小型的项目中使用 thread-loader 反而会增加构建时间