При использовании splitChunks cacheGroups commons не работает дедупликация кода - PullRequest
Новая
       9

При использовании splitChunks cacheGroups commons не работает дедупликация кода

0 голосов
/ 09 февраля 2019

У меня есть проект lerna, который содержит два идентичных пакета (названные p1 и p2)

Оба p1 и p2 включают сторонний пакет - для этого теста я использовал eosjs @ beta, который составляет около 50 КБ

Если я затем создаю пример реагирующего проекта и включаю P1, размер пакета увеличивается на 50 КБ, как и ожидалось, но меня удивляет то, что, когда я добавляю p2…, он увеличивается еще на 50 КБ.

Можно подумать, что поскольку p1 и p2 используют одну и ту же стороннюю библиотеку, одна ссылка на эту библиотеку будет скомпилирована в пример проекта.Но этого не происходит.

Пример репо здесь: https://github.com/warrick-eosny/sizetest

Рост пакета выглядит следующим образом:

ls examples / sizetest / build / static / js / -lah

Перед ссылками p1 

    117K 1.13eeb203.chunk.js     
    1.4K main.2170ea98.chunk.js  
    1.5K runtime~main.229c360f.js

После ссылки p1 

    165K 1.75baab58.chunk.js  
    3.7K main.36960386.chunk.js  
    1.5K runtime~main.229c360f.js

После ссылки p1 и p2 

    212K 1.57bb37cb.chunk.js  
    6.4K main.491260eb.chunk.js  
    1.5K runtime~main.229c360f.js

Проект в примерахпапка была создана с помощью:

npx create-response-app sizetest –typescript

Оба пакета p1 и p2 были созданы с использованием:

yo node-typescript-webpack

Почему примерная сборка продолжает расти .. Скорее всего, веб-пакет достаточно умен, чтобы включать только одну ссылку.

=============== ОБНОВЛЕНИЕ ==================

Удаление дубликатовраздел "код" здесь, кажется, должен решить мою проблему: https://developers.google.com/web/fundamentals/performance/optimizing-javascript/code-splitting/#spitting_code_by_multiple_entry_points

Но, похоже, это не так.

  1. Я запустил «извлечение пряжи» в папке проекта, а затем добавил предложенную конфигурацию: https://github.com/warrick-eosny/sizetest/blob/master/examples/sizetest/config/webpack.config.js#L196-L211
  2. Удален раздел uglyfiy, чтобы вывод читался
  3. Запустите сборку снова

Это создаст файл общего доступа, но когда вы посмотрите на содержимое: 

grep \@module build/static/js/commons.bd2f73cb.chunk.js

вы увидите, что код все еще дублируется

 * @module Serialize
 * @module Numeric
 * @module RPC-Error
 * @module Serialize
 * @module Numeric
 * @module RPC-Error
 * @module API
 * @module JSON-RPC
 * @module API
 * @module JSON-RPC

1 Ответ

0 голосов
/ 09 февраля 2019

Ни монорепо как концепция, ни Лерна как инструмент не предназначены для такого рода неявных «улучшений».Это может иметь нежелательные побочные эффекты (например, если P1 и P2 зависят от разных версий eosjs или когда каждый пакет инициирует собственный экземпляр некоторого класса пакета).

Другая причина, выступающая против выполнения того, что вы ожидаетездесь дело в том, что пакеты в monorepo все еще могут быть развернуты независимо друг от друга, потому что они не полагаются на одну и ту же ссылку на пакет.

Насколько мне известно, единственный способ добиться - это использование monorepo.что ты ищешь.Тем не менее, monorepo просто управляет вашей кодовой базой в одном месте.Если вы хотите использовать одну и ту же ссылку eosjs в обоих ваших пакетах, переместите ее на корневой уровень package.json, но тогда вам также придется столкнуться с кучей других проблем, которые вы, возможно, еще не ожидали.Вы можете сделать это вручную для ваших автономных пакетов monorepo или , подняв для внешних пакетов с Lerna: https://github.com/lerna/lerna/blob/master/doc/hoist.md

Рабочие пространства пряжи - это то, что Lerna использует подКапюшон для достижения подъема и может также помочь для понимания.

Webpack не знает о том, чтобы быть в monorepo, если вы не сказали это как-то тоже.Работает независимо от Лерны или моноропо.

...