摘要

当我们切换到使用Webpack来处理SASS文件时，我们注意到在某些情况下，构建时间变得非常缓慢。在使用SpeedMeasurePlugin测量了构建的不同部分的性能之后，似乎sass-loader是罪魁祸首……它很容易花费10s来构建（在进行一些修复之前通常花费20s），这比我们更长。 d喜欢。

我很好奇，如果人们还有其他策略可以优化构建我没有涵盖的Sass资产。在这一点上，我已经经历了很多（对于其中一些来说是多次），但似乎仍然无法将构建时间降低得足够低。就目标而言，当前的大规模重建（例如更改许多文件中使用的组件）可能很容易花费10-12秒，我希望尽可能将其降低到5s。

尝试过的解决方案

我们尝试了多种不同的解决方案，其中一些可行，而其他解决方案却无济于事。

• HardSourcePlugin-此工具相当有效。根据该构建的缓存，它能够将构建时间减少几秒钟。
• 删除重复的导入（例如将相同的“ variables.sass”文件导入多个位置）-这也将构建时间减少了几秒钟
• 将我们的SASS和SCSS组合更改为仅SCSS-我不确定为什么这样做有帮助，但似乎确实节省了我们的构建时间。也许因为所有文件都是相同的文件类型，所以更容易编译？（很可能在这里发生了其他事情，以至于混淆了结果，但似乎确实能持续地提供帮助）。
• 用fast-sass-loader代替sass- loader-很多人都建议这样做，但是当我开始使用它时，它似乎根本没有改变构建时间。我不确定为什么……也许有配置问题。
• 利用缓存加载器 -这似乎也没有任何改善。
• Sass的禁用源地图-这似乎产生了很大的影响，将构建时间减少了一半（从应用更改时开始）
• 尝试includePaths用于从node_modules加载的SASS-在我发现的git问题上建议使用此方法，在该问题上sass-loader遇到了称为“自定义进口商”的问题。我的理解是，通过使用includePaths，SASS能够依靠那些提供的绝对路径，而不是使用效率低下的算法来解析路径到诸如node_modules的位置

从一些简要的统计数据来看，我们似乎在150个SASS文件中散布了约1.6万行SASS代码。有些文件的代码量很大，而其他代码的代码量却很少，这些文件的LOC平均值约为107 LOC /文件。

以下是正在使用的配置。该应用程序是Rails应用程序，因此许多Webpack配置都是通过Webpacker gem处理的。

{
  "mode": "production",
  "output": {
    "filename": "js/[name].js",
    "chunkFilename": "js/[name].js",
    "hotUpdateChunkFilename": "js/[id]-[hash].hot-update.js",
    "path": "myApp/public/packs",
    "publicPath": "/packs/"
  },
  "resolve": {
    "extensions": [".mjs", ".js", ".sass", ".scss", ".css", ".module.sass", ".module.scss", ".module.css", ".png", ".svg", ".gif", ".jpeg", ".jpg"],
    "plugins": [{
      "topLevelLoader": {}
    }],
    "modules": ["myApp/app/assets/javascript", "myApp/app/assets/css", "node_modules"]
  },
  "resolveLoader": { …