Может кто-нибудь объяснить CommonsChunkPlugin Webpack
в общем, суть в том, что 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
, который содержит полный кодentry1.js
, требованиеjquery
и не содержит runtime -
entry2.bundle.js
, который содержит полный кодentry2.js
, требованиеjquery
и не содержит runtime -
vendors.bundle.js
что содержит полный кодsome_jquery_plugin
, требованиеjquery
и не содержит runtime -
commons.bundle.js
, который содержит полный кодjquery
и содержит среду выполнения
таким образом, мы заканчиваем с некоторыми меньшими пакетами в целом, и среда выполнения содержится в
commons
пакета. Довольно хорошо, но не идеально. -
-
Пример 2 : если я пройду
{ name : 'vendors' }
я закончу со следующим пакетом файлы:-
entry1.bundle.js
, который содержит полный кодentry1.js
, требованиеjquery
и не содержит runtime -
entry2.bundle.js
, который содержит полный кодentry2.js
, требованиеjquery
и не содержит runtime -
vendors.bundle.js
, который содержит полный кодjquery
иsome_jquery_plugin
и содержит время выполнения.
таким образом, опять же, мы в конечном итоге с некоторыми меньшими связками в целом, но среда выполнения теперь содержится в
vendors
пакета. Это немного хуже, чем в предыдущем случае, так как среда выполнения теперь находится вvendors
пакета. -
-
случай 3 : если я пройду
{ names : ['vendors', 'manifest'] }
я получу следующие файлы пакетов:-
entry1.bundle.js
, который содержит полный кодentry1.js
, требованиеjquery
и не содержит runtime -
entry2.bundle.js
, который содержит полный кодentry2.js
, требованиеjquery
и не содержит runtime -
vendors.bundle.js
, который содержит полный кодjquery
иsome_jquery_plugin
и не содержит runtime -
manifest.bundle.js
который содержит требования для каждого другого пакета и содержит среду выполнения
таким образом, мы заканчиваем с некоторыми меньшими пакетами в целом, и среда выполнения содержится в
manifest
пакета. Это идеал случай. -
чего я не понимаю/не уверен, что понимаю
на корпус 2 почему мы закончили с
vendors
пакет, содержащий общий код (jquery
) и то, что осталось отvendors
запись (some_jquery_plugin
)? Из моего понимания, что заCommonsChunkPlugin
а вот что он собрал общий код (jquery
), и так как мы заставили его вывести его наvendors
bundle, это своего рода "слияние" общий код вvendors
bundle (который теперь содержал только код изsome_jquery_plugin
). Пожалуйста, подтвердите или объясните.на корпус 3 я не понимаю, что произошло, когда мы проезжали
{ names : ['vendors', 'manifest'] }
плагину. Почему/как былоvendors
сверток сохранен нетронутым, содержащий обаjquery
иsome_jquery_plugin
, когдаjquery
явно является общей зависимостью, и почему был сгенерированmanifest.bundle.js
файл создан так, как он был создан (требуется все остальные пакеты и содержащие среду выполнения)?
1 ответов
это как CommonsChunkPlugin
строительство.
общий кусок "получает" модули, разделяемые несколькими блоками ввода. Хороший пример сложной конфигурации можно найти в папке репозиторий Webpack.
на CommonsChunkPlugin
запускается на этапе оптимизации Webpack, что означает, что он работает в памяти, непосредственно перед тем, как куски запечатаны и записаны на диск.
когда определено несколько общих блоков, они обрабатываются в порядок. В вашем случае 3 это похоже на запуск плагина дважды. Но обратите внимание, что CommonsChunkPlugin
может иметь более сложную конфигурацию (minSize, minChunks и т. д.), которая влияет на способ перемещения модулей.
Пример 1:
- есть 3
entry
блоков (entry1
,entry2
иvendors
). - настройки устанавливает
commons
chunk как общий кусок. - плагин обрабатывает
commons
общий кусок (так как кусок не существует, он создан):- он собирает модули, которые используются более одного раза в других кусках:
entry1
,entry2
иvendors
использоватьjquery
таким образом, модуль удаляется из этих кусков и добавляется вcommons
чанк. - на
commons
chunk помечен какentry
блок аentry1
,entry2
иvendors
куски не мигая, какentry
.
- он собирает модули, которые используются более одного раза в других кусках:
- наконец-то, так как
commons
кусок-этоentry
чит содержит runtime иjquery
модуль.
Пример 2:
- есть 3
entry
блоков (entry1
,entry2
иvendors
). - настройки устанавливает
vendors
chunk как общий кусок. - плагин обрабатывает
vendors
общий кусок:- он собирает модули, которые используются более одного раза в других кусках:
entry1
иentry2
использоватьjquery
таким образом, модуль удаляется из эти куски (обратите внимание ,что он не добавляется вvendors
кусок, потому чтоvendors
chunk уже содержит его). - на
vendors
chunk помечен какentry
блок аentry1
иentry2
куски unflagged какentry
.
- он собирает модули, которые используются более одного раза в других кусках:
- наконец-то, так как
vendors
чанк-этоentry
chunk, он содержит среду выполнения иjquery
/jquery_plugin
модули.
случай 3:
- есть 3
entry
блоков (entry1
,entry2
иvendors
). - настройки устанавливает
vendors
кусок иmanifest
chunk как общие куски. - плагин создает
manifest
chunk, поскольку он не существует. - плагин обрабатывает
vendors
общий кусок:- он собирает модули, которые используются более одного раза в других кусках:
entry1
иentry2
использоватьjquery
таким образом, модуль удаляется из этих кусков (обратите внимание, что он не добавляется кvendors
кусок, потому чтоvendors
chunk уже содержит его). - на
vendors
chunk помечен какentry
блок аentry1
иentry2
куски unflagged какentry
.
- он собирает модули, которые используются более одного раза в других кусках:
- плагин обрабатывает
manifest
common chunk (поскольку chunk не существует, он создается):- оно собирает модули которые использованы больше чем раз в других блоках: по мере того как никакие модули используемые больше чем раз, никакой модуль переехал.
- на
manifest
chunk помечен какentry
блок аentry1
,entry2
иvendors
находятся непомеченные какentry
.
- наконец-то, так как
manifest
чанк-этоentry
chunk содержит среду выполнения.
надеюсь, что это помогает.