Может кто-нибудь объяснить 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:

  1. есть 3 entry блоков (entry1, entry2 и vendors).
  2. настройки устанавливает commons chunk как общий кусок.
  3. плагин обрабатывает commons общий кусок (так как кусок не существует, он создан):
    1. он собирает модули, которые используются более одного раза в других кусках:entry1, entry2 и vendors использовать jquery таким образом, модуль удаляется из этих кусков и добавляется в commons чанк.
    2. на commons chunk помечен как entry блок а entry1, entry2 и vendors куски не мигая, как entry.
  4. наконец-то, так как commons кусок-это entry чит содержит runtime и jquery модуль.

Пример 2:

  1. есть 3 entry блоков (entry1, entry2 и vendors).
  2. настройки устанавливает vendors chunk как общий кусок.
  3. плагин обрабатывает vendors общий кусок:
    1. он собирает модули, которые используются более одного раза в других кусках:entry1 и entry2 использовать jquery таким образом, модуль удаляется из эти куски (обратите внимание ,что он не добавляется в vendors кусок, потому что vendors chunk уже содержит его).
    2. на vendors chunk помечен как entry блок а entry1 и entry2 куски unflagged как entry.
  4. наконец-то, так как vendors чанк-это entry chunk, он содержит среду выполнения и jquery/jquery_plugin модули.

случай 3:

  1. есть 3 entry блоков (entry1, entry2 и vendors).
  2. настройки устанавливает vendors кусок и manifest chunk как общие куски.
  3. плагин создает manifest chunk, поскольку он не существует.
  4. плагин обрабатывает vendors общий кусок:
    1. он собирает модули, которые используются более одного раза в других кусках:entry1 и entry2 использовать jquery таким образом, модуль удаляется из этих кусков (обратите внимание, что он не добавляется к vendors кусок, потому что vendors chunk уже содержит его).
    2. на vendors chunk помечен как entry блок а entry1 и entry2 куски unflagged как entry.
  5. плагин обрабатывает manifest common chunk (поскольку chunk не существует, он создается):
    1. оно собирает модули которые использованы больше чем раз в других блоках: по мере того как никакие модули используемые больше чем раз, никакой модуль переехал.
    2. на manifest chunk помечен как entry блок а entry1, entry2 и vendors находятся непомеченные как entry.
  6. наконец-то, так как manifest чанк-это entry chunk содержит среду выполнения.

надеюсь, что это помогает.