Может кто-нибудь объяснить Webpack CommonsChunkPlugin

Я понимаю общий смысл, что CommonsChunkPlugin просматривает все точки входа, проверяет, есть ли между ними общие пакеты/зависимости, и разделяет их на отдельные пакеты.

Итак, предположим, что у меня есть следующая конфигурация:

...
enrty : {
    entry1 : 'entry1.js', //which has 'jquery' as a dependency
    entry2 : 'entry2.js', //which has 'jquery as a dependency
    vendors : [
        'jquery',
        'some_jquery_plugin' //which has 'jquery' as a dependency
    ]
},
output: {
    path: PATHS.build,
    filename: '[name].bundle.js'
}
...

Если я свяжу без использования `CommonsChunkPlugin`

Я закончу с 3 новыми файлами пакетов:

entry1.bundle.js, который содержит полный код из entry1.js и jquery и содержит собственную среду выполнения
entry2.bundle.js, который содержит полный код из entry2.js и jquery и содержит собственную среду выполнения
vendors.bundle.js, который содержит полный код из jquery и some_jquery_plugin и содержит собственную среду выполнения

Это явно плохо, потому что потенциально я буду загружать страницу jquery 3 раза, а нам это не нужно.

Если я связываю с помощью `CommonsChunkPlugin`

В зависимости от того, какие аргументы я передаю CommonsChunkPlugin, произойдет одно из следующего:

СЛУЧАЙ 1. Если я пройду { name : 'commons' }, я получу следующие файлы пакета:
- entry1.bundle.js which contains the complete code from entry1.js, a requirement for jquery and does not contain the runtime
- entry2.bundle.js, который содержит полный код из entry2.js, требование для jquery и не содержит среды выполнения
- vendors.bundle.js, который содержит полный код из some_jquery_plugin, требование для jquery и не содержит среды выполнения
- commons.bundle.js, который содержит полный код из jquery и содержит среду выполнения
Таким образом, мы получим в целом несколько меньших пакетов, а среда выполнения будет содержаться в пакете commons. Вполне нормально, но не идеально.
СЛУЧАЙ 2. Если я пропущу { name : 'vendors' }, я получу следующие файлы пакета:
- entry1.bundle.js which contains the complete code from entry1.js, a requirement for jquery and does not contain the runtime
- entry2.bundle.js, который содержит полный код из entry2.js, является требованием для jquery и не содержит среды выполнения.
- vendors.bundle.js, который содержит полный код из jquery и some_jquery_plugin и содержит среду выполнения.
Таким образом, опять же, мы получим в целом несколько меньших пакетов, но среда выполнения теперь содержится в пакете vendors. Это немного хуже, чем в предыдущем случае, так как среда выполнения теперь находится в комплекте vendors.
СЛУЧАЙ 3. Если я пропущу { names : ['vendors', 'manifest'] }, я получу следующие файлы пакета:
- entry1.bundle.js which contains the complete code from entry1.js, a requirement for jquery and does not contain the runtime
- entry2.bundle.js, который содержит полный код из entry2.js, требование для jquery и не содержит среды выполнения
- vendors.bundle.js, который содержит полный код из jquery и some_jquery_plugin и не содержит среды выполнения
- manifest.bundle.js, который содержит требования для всех остальных пакетов и содержит среду выполнения
Таким образом, мы получаем в целом несколько меньших пакетов, а среда выполнения содержится в пакете manifest. Это идеальный случай.

Что я не понимаю / я не уверен, что понимаю

Почему в СЛУЧАЕ 2 мы получили пакет vendors, содержащий как общий код (jquery), так и то, что осталось от записи vendors (some_jquery_plugin)? Насколько я понимаю, CommonsChunkPlugin здесь собирал общий код (jquery), и поскольку мы заставили его выводить его в пакет vendors, он как бы "слил" общий код в пакет vendors (который теперь только содержал код от some_jquery_plugin). Подтвердите или объясните.
В СЛУЧАЕ 3 я не понимаю, что произошло, когда мы передали { names : ['vendors', 'manifest'] } подключаемому модулю. Почему/как пакет vendors был сохранен нетронутым, содержащим как jquery, так и some_jquery_plugin, когда jquery явно является общей зависимостью, и почему сгенерированный файл manifest.bundle.js был создан так, как он был создан (требующий всех других пакетов и содержащий среду выполнения)?

Dimitris Karagiannis 17.09.2016 источник

comment

Для случая 1, я думаю, вы должны указать свойство minChunks. - Marko 19.09.2016

comment

Я многому научился из вашего вопроса, большое спасибо! - Rafael Eyng 31.05.2017

comment

Большое спасибо, что спросили об этом и прояснили мои недоразумения все это время с этим плагином ❤ - Glenn Mohammad 29.10.2017

comment

Может кто знает, как эти примеры будут выглядеть в Webpack 4? - StalkAlex 08.03.2018

Ответы (1)

arrow_upward
105
arrow_downward

Вот как работает CommonsChunkPlugin.

Общий блок «получает» модули, совместно используемые несколькими входными блоками. Хороший пример сложной конфигурации можно найти в репозитории Webpack< /а>.

CommonsChunkPlugin запускается на этапе оптимизации Webpack, что означает, что он работает в памяти, непосредственно перед тем, как фрагменты будут запечатаны и записаны на диск.

Когда определены несколько общих фрагментов, они обрабатываются по порядку. В вашем случае 3 это похоже на двойной запуск плагина. Но обратите внимание, что CommonsChunkPlugin может иметь более сложную конфигурацию (minSize, minChunks и т. д.), которая влияет на способ перемещения модулей.

СЛУЧАЙ 1:

Есть 3 фрагмента entry (entry1, entry2 и vendors).
Конфигурация устанавливает чанк commons как общий чанк.
The plugin processes the commons common chunk (since the chunk does not exist, it is created):
1. It collects the modules that are used more than once in the other chunks: entry1, entry2 and vendors use jquery so the module is removed from these chunks and is added to the commons chunk.
2. Фрагмент commons помечается как фрагмент entry, а фрагменты entry1, entry2 и vendors не помечаются как entry.
Наконец, поскольку фрагмент commons является фрагментом entry, он содержит среду выполнения и модуль jquery.

СЛУЧАЙ 2:

Есть 3 фрагмента entry (entry1, entry2 и vendors).
Конфигурация устанавливает чанк vendors как общий чанк.
The plugin processes the vendors common chunk:
1. It collects the modules that are used more than once in the other chunks: entry1 and entry2 use jquery so the module is removed from these chunks (note that it is not added to the vendors chunk because the vendors chunk already contains it).
2. Фрагмент vendors помечается как фрагмент entry, а фрагменты entry1 и entry2 не помечаются как entry.
Наконец, поскольку фрагмент vendors является фрагментом entry, он содержит среду выполнения и модули jquery/jquery_plugin.

СЛУЧАЙ 3:

Есть 3 фрагмента entry (entry1, entry2 и vendors).
Конфигурация устанавливает фрагмент vendors и фрагмент manifest как общие фрагменты.
Плагин создает фрагмент manifest, так как он не существует.
The plugin processes the vendors common chunk:
1. It collects the modules that are used more than once in the other chunks: entry1 and entry2 use jquery so the module is removed from these chunks (note that it is not added to the vendors chunk because the vendors chunk already contains it).
2. Фрагмент vendors помечается как фрагмент entry, а фрагменты entry1 и entry2 не помечаются как entry.
The plugin processes the manifest common chunk (since the chunk does not exist, it is created):
1. It collects the modules that are used more than once in the other chunks: as there are no modules used more than once, no module is moved.
2. Фрагмент manifest помечен как фрагмент entry, а фрагменты entry1, entry2 и vendors не помечены как entry.
Наконец, поскольку фрагмент manifest является фрагментом entry, он содержит среду выполнения.