限制 loader 应用范围

  1. 思路是：对于某些库，不使用 loader ，例如：babel-loader 可以转换 ES6 或更高版本的语法，可是有些库本身就是用 ES5 语法书写的，不需要转换，使用 babel-loader 反而会浪费构建时间；

  2. lodash 是在 ES5 之前出现的库，使用的是 ES3 语法：

    • 通过 module.rule.exclude 或 module.rule.include，排除或仅包含需要应用 loader 的场景
    module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /lodash/,
                use: "babel-loader"
            }
        ]
    }
}
    • 如果暴力一点，甚至可以排除掉 node_modules 目录中的模块，或仅转换 src 目录的模块
    module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                //或
                // include: /src/,
                use: "babel-loader"
            }
        ]
    }
}

    这种做法是对 loader 的范围进行进一步的限制，和 noParse 不冲突

缓存 loader 结果

  1. 如果某个文件内容不变，经过相同的 loader 解析后，解析后的结果也不变，于是可以将 loader 的解析结果保存下来，让后续的解析直接使用保存的结果；

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

    module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: ['cache-loader', ...loaders]
      },
    ],
  },
};

  3. 有趣的是 cache-loader 放到最前面，却能够决定后续的 loader 是否运行，实际上 loader 的运行过程中，还包含一个过程 pitch

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

为 loader 开启多线程

  1. thread-loader 会开启一个线程池，线程池中包含适量的线程，它会把后续的 loader 放到线程池的线程中运行，以提高构建效率；

  2. 由于后续的 loader 会放到新的线程中，所以后续的 loader 不能：

    • 使用 webpack api 生成文件
    • 无法使用自定义的 plugin api
    • 无法访问 webpack options

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

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

打赏作者
您的打赏是我前进的动力
微信
支付宝
评论

中午好👏🏻，我是 ✍🏻   疯狂 codding 中...

粽子

这有关于产品、设计、开发的问题和看法，还有技术文档和你分享。

相信你可以在这里找到对你有用的知识和教程

了解更多

目录

  1. 1. 限制 loader 应用范围
  2. 2. 缓存 loader 结果
  3. 3. 为 loader 开启多线程