92% оптимизация основных средств - веб-пакет

Question

Похоже, что веб-пакет застрял на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 devtools)?

Answer 1

Я тоже столкнулся с подобной проблемой при удаленном запуске сборки, поэтому в jenkin после добавления следующей команды проблема была решена для меня.

export "NODE_OPTIONS=--max_old_space_size=2000"

Answer 2

Я выполняю очистку кеша пряжи, и это устранило мою проблему "92% оптимизации фрагментов TerserPlugin" на моем хосте Ubuntu 16.04 в облаке Google.

Не уверен, работает ли он на вашем компьютере

yarn cache clean

У меня эта проблема на 2-м компьютере, и этот компьютер требует перезагрузки.

sudo reboot

Answer 3

Запустите " ng serve --sourceMap=false "

Answer 4

Я имел большой успех, используя следующие комбинации:

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

а также

https://github.com/amireh/happypack

HardSourceWebpackPlugin - это плагин для веб-пакета, обеспечивающий промежуточный этап кэширования для модулей. Чтобы увидеть результаты, вам нужно запустить webpack дважды с этим плагином: первая сборка займет нормальное количество времени. Вторая сборка будет значительно быстрее.

HappyPack ускоряет первоначальную сборку веб-пакетов путем параллельного преобразования файлов.

Сообщите обратно и дайте мне знать, как это происходит.

Answer 5

У меня такая же проблема со следующими характеристиками

      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
}

Итак, что выше, это говорит веб-пакету не уменьшать файлы (поэтому проблема заключалась в том, что у меня была пара файлов размером около 20 МБ, сгенерированных одной из внешних библиотек, и веб-пакет пытался их минимизировать)

для получения дополнительной информации посетите 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
          }
        }
      ]
    })
  ]
});

Я хотел бы отдать должное этому ответу /questions/38170568/webpack-kopirovanie-fajlov-iz-ishodnogo-v-obschedostupnoe-s-ispolzovaniem-copywebpackplugin/60295653#60295653, поскольку он помог мне найти это решение.

Answer 6

Для меня 92% chunk-актива занимало вечность, поэтому я решил позволить ему работать на ночь, после чего я получил следующую ошибку:

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - куча JavaScript из памяти

Решение. Основная проблема заключается в том, что для узла по умолчанию установлено ограничение памяти 1,76 ГБ. Если вам нужно больше, вам нужно установить опцию --max_old_space_size={желаемый размер} при запуске процесса узла.

Попробуйте увеличить лимит памяти:

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

Answer 7

Любой, кто пытается решить эту проблему с помощью Node с Angular CLI в Windows 10;

Убедитесь, что каталог, в который выполняется запись, имеет соответствующие разрешения на запись. У меня возникла именно эта проблема при попытке записи в c:/Users/UserName/Documents/SoultionDir

Для меня это может быть связано с политикой использования компании.

Сообщение "92% оптимизации фрагментов TerserPlugin" появляется непосредственно перед записью в папку. Если разрешения неправильные, он тихо вылетает и зависает навсегда. Измените каталог на тот, который, как вы знаете, имеет правильные разрешения для записи, используя командную строку администратора.

Answer 8

Наконец-то я получил решение этой проблемы. Вся эта игра про память. В процессе сборки сборщику потребовалось некоторое количество свободной памяти. В моем случае, когда я останавливал все процессы pm2, освобождалась пара памяти, и сборщик использовал ее для своего процесса, и я думал, что pm2 создает проблему. Эта проблема возникала у меня каждый раз, когда я увеличивал раздел памяти подкачки в 2019 году, и с того дня и по сей день у меня больше никогда не возникало такой проблемы, и я работал без остановки pm2.

Answer 9

В 2023 году та же проблема все еще возникает, в моем случае, с webpack-4 через Webpacker.

Происходит, когдаparallelНастройка в плагине terser-webpack-plugin слишком высока. В моем случае это было 10, что является значением по умолчанию в Webpacker.

Уменьшите его до меньшего значения (например, 2), и сборка пройдет нормально.

Answer 10

Я столкнулся с той же проблемой во время выполнения ng build команда.

Я получил следующую ошибку:

Оптимизация активов на 92%

Процесс был остановлен на 92%, но следующие команды работают нормально для меня.

Попробуйте это:

pm2 stop all

ng build

pm2 start all

я использую pm2 как мой менеджер процесса.

Я надеюсь, что это работает и для вас.