📝 Собирая большой проект вебпаком можно заметить, что прогресс сборки довольно долгое время может висеть примерно на 66-68%. Это связано с тем, что по умолчанию прогресс рассчитывается как отношение количества уже собранных модулей на общее количество модулей. Вроде бы логично, но проблема в том, что вебпак заранее не знает сколько всего модулей в проекте, потому как в любой момент времени любой лоадер может докинуть еще пару сотен модулей. Общее количеством модулей растет по мере сборки, растет и количество собранных модулей, отсюда и дерганье процента прогресса. Выйти из положения можно явно указав в настройках ProgressPlugin примерное количество модулей в вашем проекте:
new ProgressPlugin({ modulesCount: 10000 });
То есть сначала нужно один раз собрать проект, как-то подсмотреть общее количество модулей и затем указать эту цифру в настройках плагина и обновлять ее вручную с какой-то периодичностью. Можно еще написать скрипт, который перед стартом сборки считает количество файлов в проекте и указывает эту цифру в конфиге ProgressPlugin. Это из расчета, что одному файлу соответствует один модуль, а это не всегда так. Плюс ко всему, не понятно как считать node_modules, т.к. не все модули могут использоваться в вашем проекте. В общем, такие себе решения…
Года полтора назад, переводя на вебпак действительно большой проект, я подумал о том, что для больших проектов лучше считать процент не по количеcтву модулей, а по количество точек входа, коих в больших проектах всегда много, скорее всего никому не придет в голову загонять огромный проект под одну точку входа, за редким исключением. Сделал PR в вебпак. Его смысл был в том, чтобы считать прогресс как отношение количества собранных точек входа к общему количеству точек входа. Преимущество такого подхода в том, что общее количество точек входа всегда известно заранее и во время сборки не изменяется. Мой PR тогда приняли только наполовину, т.к. мне не удалось договориться с Тобиасом (автор вебпака) по поводу того, как реализовать пересчет процентов на основании точек входа и мы решили оставить только текстовое инфо. То есть теперь в консоли хотя бы можно было видеть что-то вроде 252/420 - то есть сколько точек входа собрано и сколько их всего.
Буквально недавно замержили еще один мой PR в webpack 5, в котором можно выбирать как именно нужно высчитывать процент готовности. По умолчанию, процент все так же считается по количеству модулей, но через параметр percentBy это поведение можно изменить, например, чтобы начать считать процент готовности по точкам входа, то достаточно сделать так:
new ProgressPlugin({ percentBy: 'entries' });
Но и это еще не всё, пока я писал этот пост, мне в голову пришла еще одна, казалось бы очевидная, идея. Я подумал о том, что когда вебпак заканчивает сборку, можно сохранять в кеше количество собранных модулей и восстанавливать их на старте следующей сборки. Да, первая сборка будет разогревать кеш, а последующие уже будут использовать инфо из кеша и обновлять его автоматически. Вряд ли между сборками кодовая база изменится так, что количество модулей резко изменится, ну или вряд ли это будет происходить слишком часто.
P.S.: Добавил этот пост в канал сразу же после того, как мой PR был замержен в мастер 😅 Можно будет попробовать в beta.14
📝 Собирая большой проект вебпаком можно заметить, что прогресс сборки довольно долгое время может висеть примерно на 66-68%. Это связано с тем, что по умолчанию прогресс рассчитывается как отношение количества уже собранных модулей на общее количество модулей. Вроде бы логично, но проблема в том, что вебпак заранее не знает сколько всего модулей в проекте, потому как в любой момент времени любой лоадер может докинуть еще пару сотен модулей. Общее количеством модулей растет по мере сборки, растет и количество собранных модулей, отсюда и дерганье процента прогресса. Выйти из положения можно явно указав в настройках ProgressPlugin примерное количество модулей в вашем проекте:
new ProgressPlugin({ modulesCount: 10000 });
То есть сначала нужно один раз собрать проект, как-то подсмотреть общее количество модулей и затем указать эту цифру в настройках плагина и обновлять ее вручную с какой-то периодичностью. Можно еще написать скрипт, который перед стартом сборки считает количество файлов в проекте и указывает эту цифру в конфиге ProgressPlugin. Это из расчета, что одному файлу соответствует один модуль, а это не всегда так. Плюс ко всему, не понятно как считать node_modules, т.к. не все модули могут использоваться в вашем проекте. В общем, такие себе решения…
Года полтора назад, переводя на вебпак действительно большой проект, я подумал о том, что для больших проектов лучше считать процент не по количеcтву модулей, а по количество точек входа, коих в больших проектах всегда много, скорее всего никому не придет в голову загонять огромный проект под одну точку входа, за редким исключением. Сделал PR в вебпак. Его смысл был в том, чтобы считать прогресс как отношение количества собранных точек входа к общему количеству точек входа. Преимущество такого подхода в том, что общее количество точек входа всегда известно заранее и во время сборки не изменяется. Мой PR тогда приняли только наполовину, т.к. мне не удалось договориться с Тобиасом (автор вебпака) по поводу того, как реализовать пересчет процентов на основании точек входа и мы решили оставить только текстовое инфо. То есть теперь в консоли хотя бы можно было видеть что-то вроде 252/420 - то есть сколько точек входа собрано и сколько их всего.
Буквально недавно замержили еще один мой PR в webpack 5, в котором можно выбирать как именно нужно высчитывать процент готовности. По умолчанию, процент все так же считается по количеству модулей, но через параметр percentBy это поведение можно изменить, например, чтобы начать считать процент готовности по точкам входа, то достаточно сделать так:
new ProgressPlugin({ percentBy: 'entries' });
Но и это еще не всё, пока я писал этот пост, мне в голову пришла еще одна, казалось бы очевидная, идея. Я подумал о том, что когда вебпак заканчивает сборку, можно сохранять в кеше количество собранных модулей и восстанавливать их на старте следующей сборки. Да, первая сборка будет разогревать кеш, а последующие уже будут использовать инфо из кеша и обновлять его автоматически. Вряд ли между сборками кодовая база изменится так, что количество модулей резко изменится, ну или вряд ли это будет происходить слишком часто.
P.S.: Добавил этот пост в канал сразу же после того, как мой PR был замержен в мастер 😅 Можно будет попробовать в beta.14
During a meeting with the president of the Supreme Electoral Court (TSE) on June 6, Telegram's Vice President Ilya Perekopsky announced the initiatives. According to the executive, Brazil is the first country in the world where Telegram is introducing the features, which could be expanded to other countries facing threats to democracy through the dissemination of false content. Hui said the messages, which included urging the disruption of airport operations, were attempts to incite followers to make use of poisonous, corrosive or flammable substances to vandalize police vehicles, and also called on others to make weapons to harm police. To view your bio, click the Menu icon and select “View channel info.” With the sharp downturn in the crypto market, yelling has become a coping mechanism for many crypto traders. This screaming therapy became popular after the surge of Goblintown Ethereum NFTs at the end of May or early June. Here, holders made incoherent groaning sounds in late-night Twitter spaces. They also role-played as urine-loving Goblin creatures. A new window will come up. Enter your channel name and bio. (See the character limits above.) Click “Create.”
from us
