Блог

Написание пакета NPM, содержащего модули es6, рекомендуется ли хранить исходные файлы отдельно

 package.json
esm
 index.js
 Content1
  Content1A.js
  Content1A.js.map
  Content1B.js
  Content1B.js.map
 Content2
  Content2A.js
  Content2A.js.map
  Content2B.js
  Content2B.js.map
 

со index.js ссылками на содержимое во вложенных папках или лучше объединить его в один файл

 package.json
esm
 contents.js
 contents.js.map
 

Похоже, что первый метод имеет преимущество с модулями CommonJS, поскольку он дает потребителю возможность импортировать непосредственно из источника и, таким образом, пропускать неиспользуемые импортные данные index.js (поскольку модули CommonJS не могут изменяться в дереве), но с модулями es6 этот аргумент исчезает.

Разные упаковщики могут быть способны на разные вещи. Остальная часть этого ответа относится к Webpack, который, будучи одним из наиболее распространенных пакетов, должен влиять на решения в этой области.

Наиболее важный фактор, определяющий решение о том, объединять вашу библиотеку или нет, должен быть связан с встряхиванием деревьев. Никакие другие важные аспекты не приходят мне на ум.

Параметры, влияющие на встряхивание деревьев в Webpack

1. sideEffects: false

Параметр package.json , указывающий, имеют ли модули в пакете побочные эффекты, которые необходимо выполнить, когда модуль импортирован, но не используется. Установка этого значения false указывает на то, что никакие модули не имеют побочных эффектов. Также может быть установлен список модулей, которые имеют побочные эффекты и другие более сложные значения. По умолчанию, похоже true , указано, что все модули имеют побочные эффекты.

Эти параметры играют большую роль при использовании индекса точки входа в пакете, из которого реэкспортируются все экспортируемые пакеты. Разреженный импорт из этого индекса может легко привести к тому, что весь ваш пакет будет упакован, если этот параметр неверен.

2. optimization.usedExports: true

Настройка, webpack.config.js указывающая Webpack, что все неиспользуемые экспортные данные могут быть исключены. Это активирует эвристику, используемую Terser для удаления неиспользуемого кода внутри модуля. true По умолчанию установлено значение.

В игрушечных сценариях эта настройка может показаться достаточно эффективной, и sideEffects флаг может показаться, что он не играет большой роли. Это не относится к реальным сценариям с более сложным кодом, где этой эвристике сложнее выполнить хорошую работу.

3. /*#__PURE__*/

Аннотация, которая должна использоваться перед операторами (например, функциями), чтобы указать, что они могут быть исключены, если не используются явно. Эти аннотации также играют определенную роль в эвристике, используемой Terser для удаления неиспользуемого кода внутри модуля.

Вывод

Чтобы ваши потребители могли извлечь максимальную выгоду из встряхивания деревьев, рекомендуется не связывать пакет es6 npm, а вместо этого разрешить отдельным входным модулям оставаться отдельными, чтобы sideEffects настройка package.json могла привести к тому, что потребительский комплект будет обрезать как можно больше неиспользуемых модулей. Полагайтесь на optimization.usedExports внутренние модули, оценивайте содержимое пакета и добавляйте /*#__PURE__*/ аннотации там, где, по вашему мнению, это может иметь большое значение. Если все упаковано в один и тот же файл, sideEffects флаг в package.json не могу выполнить основную часть работы, так как все находится в одном модуле, и впоследствии нам приходится полагаться на множество дополнительных /*#__PURE__*/ аннотаций и эвристик в пакете для потребителей, чтобы сделать встряхивание дерева максимально эффективным, что требует от вас большего (с точки зрения аннотаций) и не дает никаких особых преимуществ. Не забудьте создать свой пакет в рабочем режиме, так как в противном случае оптимизация не всегда активна.

Источник

• https://webpack.js.org/guides/tree-shaking/
• Собственные эксперименты