92%的代码块资源优化 - webpack

37

看起来webpack在92%的块资产优化时卡住了,用了30多秒的时间才展示一个简单的js/css更改。这对于任何理智的人来说等待那么长时间来看应该立即呈现的东西是太长了。

我们处于开发模式(所以我们需要源映射,这会增加延迟),但它仍然不应该需要30多秒。此外,我们没有使用uglify(我在GitHub上看到它花费了相当长的时间)。

我们应该如何使构建时间接近即时或比现在快得多?

更新

这是laravel-mix文件:

let mix = require('laravel-mix');

mix.react('resources/assets/js/app.js', 'public/js')
   .sass('resources/assets/sass/app.scss', 'public/css')
   .options({
     processCssUrls: false
   });

mix.webpackConfig({
    // Note: First build will always be slower regardless
    // Here we're talking about rebuild time

    // If commented out, rebuild is ~6 secs
    // devtool: "inline-source-map",

    // If not commented out, rebuild is 30+ secs
    devtool: "inline-source-map",
});

我发现inline-source-map是最适合快速调试的,因为它提供了在源代码中修复错误的最详细信息,非常直接明了。我觉得与其他类型相比更加清晰易懂,没有指示在源代码中修复哪一行错误,因此调试需要花费更长的时间。

你们是如何做到的?是否有一种可以快速重建并且仍然能够通过显示在Chrome开发者工具控制台中的错误行号来进行调试的方法?


你能分享一下你的webpack配置吗?或者至少提供一个外部链接让我查看它?我曾经在一些中大型项目中使用过webpack,在开发模式下,只需要半秒钟就可以应用更改。关键是要从你的加载器中排除node_modules,并将供应商放在单独的入口中。也许你正在每次构建时编译所有的node_modules。 - The.Bear
使用默认的 Laravel Mix Webpack 配置(使用多个文件),但我们可以覆盖 webpack 配置(https://github.com/JeffreyWay/laravel-mix/blob/master/docs/quick-webpack-configuration.md)。 - Wonka
@The.Bear,你能分享一下如何排除 node_modules 的方法吗?我还是遇到了问题。 - Wonka
我想你正在使用babel来处理reactjs,可以参考这个链接https://github.com/babel/babel-loader#troubleshooting。 - The.Bear
另一个问题是如果您有大量依赖项,最好的方法是为供应商单独创建一个条目,这样当您保存src文件时,供应商不会被编译。这可以节省很多时间。但我不理解您分享的github,laravel webpack mix(我甚至从未使用过laravel)。我找不到webpack.config的位置。如果您可以在问题中粘贴生成的webpack配置,我可以帮助您。 - The.Bear
我相信这些是创建它的webpack文件: https://github.com/JeffreyWay/laravel-mix/tree/5a481eae7eecbffa28d6dbb61ca061b165b52099/src/builder 早期的链接只是展示我们可以添加自定义规则而不必触碰实际的webpack配置文件(因为它由许多文件组成)。然而,这使得调试有点困难 :/ - Wonka
10个回答

11

我在远程运行构建时也遇到了类似的问题,所以在Jenkins中添加以下命令后,我的问题得到了解决。

export "NODE_OPTIONS=--max_old_space_size=2000"

我尝试了这个命令。有时候它有效,有时候不行。 - Arashdeep Singh

4
我执行了一个 yarn 缓存清理 ,它解决了我在谷歌云的 Ubuntu 16.04 主机上遇到的 "92% chunk asset optimization TerserPlugin" 问题。但不确定它是否适用于您的机器。
yarn cache clean

我在第二台机器上遇到了这个问题,而且这台机器需要重新启动。

sudo reboot

3

运行 ng serve --sourceMap=false


2

我使用以下组合取得了很大的成功:

https://github.com/mzgoddard/hard-source-webpack-plugin

并且

https://github.com/amireh/happypack

HardSourceWebpackPlugin是webpack的一个插件,为模块提供了中间缓存步骤。要看到结果,您需要使用此插件运行两次webpack:第一次构建将花费正常的时间。第二次构建将显着加快速度。
HappyPack通过并行转换文件使初始webpack构建更快。
回报并让我知道进展如何。

谢谢@KFE,但如果可能的话,我正在寻找一些没有额外包的东西。正如我在更新中发布的那样,源映射似乎是减速的原因,现在需要大约6秒钟来重建,但无法进行良好的调试,因此将问题集中在更新上。 - Wonka
嗨KFE,你觉得把这个插件接入Angular CLI可行吗?能够进行更多的并行处理对我来说非常有趣。 - Astronaut
@Astronaut 我不知道它是否适用于angular cli,因为我没有使用过。但是这确实可以与angular 1.6 x webpack设置一起使用。 - KFE

0

我遇到了与以下规格相同的问题

webpack version 5.69.0

我的webpack复制插件选项

new CopyPlugin({
  patterns: [
    {
      to({ context, absoluteFilename }) {
        return `./${path.relative(context, absoluteFilename)}`;
      },
      from: 'public',
      globOptions: {
        ignore: ['**/index.html']
      }
    }
  ]
})

我是如何解决的,是在现有配置的基础上添加了这些选项

info: {
   minimized: true
}

所以上面的代码告诉webpack不要压缩文件(问题是我有几个由外部库生成的大约20MB的文件,而webpack试图对它们进行压缩)

欲了解更多信息,请访问https://www.npmjs.com/package/copy-webpack-plugin#info

因此,最终的webpack.prod.js配置为

const { merge } = require('webpack-merge');
const path = require('path');
const common = require('./webpack.common.js');
const CopyPlugin = require('copy-webpack-plugin');

module.exports = merge(common, {
  mode: 'production',
  plugins: [
    new CopyPlugin({
      patterns: [
        {
          to({ context, absoluteFilename }) {
            return `./${path.relative(context, absoluteFilename)}`;
          },
          from: 'public',
          globOptions: {
            ignore: ['**/index.html']
          },
          info: {
            minimized: true
          }
        }
      ]
    })
  ]
});

我想要感谢这个答案https://dev59.com/cVcO5IYBdhLWcg3w7lvq#69081475,因为它帮助我找到了这个解决方案。


0

如果您在使用Windows 10上的Node和Angular CLI时遇到此问题,请注意CLI正在写入的目录是否具有适当的写入权限。 当我尝试写入c:/Users/UserName/Documents/SoultionDir时,我遇到了这个确切的问题。

对我来说,可能与公司使用政策有关。
"92% chunk asset optimization TerserPlugin"消息出现在写入文件夹之前。 如果权限不正确,则会无声地崩溃并永久挂起。 请使用管理员命令提示符将目录更改为您知道具有正确写入权限的目录。


你能详细说明一下你做了什么吗?我们公司也有相关规定,如果你能提供详细的指导,那就太好了。 - Shafiq Jetha
我认为“文档”文件夹的权限有些奇怪。我不确定具体是什么问题。 我使用的文件夹是“C:\Users\username\source” 文件夹名称“source”是任意的 - 您可以根据需要更改它。 - Aeptitude

0

对我来说,92%的块资产需要很长时间,所以我决定让它在夜间运行,但后来我收到了以下错误:

致命错误:CALL_AND_RETRY_LAST 分配失败 - JavaScript堆内存不足

解决方案:核心问题是node默认内存限制为1.76 GB。如果您需要更多内存,则需要在启动node进程时设置选项--max_old_space_size={desiredSize}。

尝试增加内存限制:

https://www.npmjs.com/package/increase-memory-limit


0
2023年,同样的问题仍然发生在我的情况下,使用webpack-4通过Webpacker
terser-webpack-plugin中的parallel设置过高时会发生这种情况。在我的情况下,它是10,这是Webpacker的默认值。
将其降低到较低的值(如2),构建就会顺利进行。

0
终于,我找到了解决这个问题的方法。整个问题的关键在于内存。在构建过程中,构建器需要一些可用内存。在我的情况下,当我停止所有的pm2进程时,会释放一些内存,构建器会利用这些内存进行处理,我以为是pm2造成了问题。每次都会遇到这个问题,后来我在2019年增加了交换内存分区,从那天起到现在,再也没有遇到同样的问题,并且在没有停止pm2的情况下正常工作。

-4

在执行ng build命令时,我遇到了同样的问题。

我收到了以下错误信息:

92% chunk asset optimizationKilled

进程在92%处停止,但是以下命令对我来说运行良好。

请尝试这些命令:

pm2 stop all

ng build

pm2 start all

我正在使用pm2作为我的进程管理器。

希望它对你也有用。


此处与所询问的问题无关,甚至没有提到他们是否正在使用pm2。 - Krzysztof Krzeszewski
是的,你说得对。 终于,我找到了解决这个问题的方法。 整个游戏都是关于内存的。 在构建过程中,构建器需要一些空闲内存。 在我的情况下,当我停止所有的pm2进程时,会释放一些内存,构建器会使用这些内存进行他们的进程,我以为是pm2创建了问题。 我每次都遇到这个问题,然后我增加了2019年的交换内存分区,从那天起直到现在,再也没有遇到同样的问题,并且可以在没有pm2停止的情况下工作。 - hardy

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接