Преимущества bundledDependencies по сравнению с обычными зависимостями в NPM

Question

npm позволяет нам указать bundledDependencies, но каковы преимущества этого? Я предполагаю, что если мы хотим быть абсолютно уверенными, что получим правильную версию, даже если модуль, на который мы ссылаемся, будет удален, или, возможно, выигрыш в скорости при объединении?

Кто-нибудь знает преимущества bundledDependencies по сравнению с обычными зависимостями?

Извлечение определения связанных зависимостей здесь для удобства:

bundledDependencies
Массив имен пакетов, которые будут упакованы при публикации пакета.

Если это записано как "bundleDependencies", то это тоже почетно.

Например bundledDependencies: ['foo', 'bar']

Answer 1

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

Использование bundledDependencies - это способ обойти эту проблему, гарантируя, как вы правильно предполагаете, что вы всегда будете поставлять правильные зависимости, независимо от того, что еще может изменяться.

Вы также можете использовать это, чтобы собрать свои собственные, частные пакеты и доставить их вместе с установкой.

Answer 2

Для быстрого чтения: этот QA касается поля package.json bundledDependencies, а не пакета.

Что в комплекте

"bundledDependencies" - это именно то, что подразумевает их имя. Зависимости, которые должны быть внутри вашего проекта. Таким образом, функциональность в основном такая же, как и в обычных зависимостях. Они также будут упакованы при запуске npm pack,

Когда их использовать

Обычные зависимости обычно устанавливаются из реестра npm. Таким образом, связанные зависимости полезны, когда:

• Вы хотите повторно использовать стороннюю библиотеку, которая не входит в реестр npm или была изменена
• Вы хотите повторно использовать свои собственные проекты в качестве модулей
• Вы хотите распространять некоторые файлы с вашим модулем

Таким образом, вам не нужно создавать (и поддерживать) свой собственный репозиторий npm, но вы получаете те же преимущества, что и пакеты npm.

Когда не следует использовать связанные зависимости

При разработке я не думаю, что главное - это предотвратить случайные обновления. У нас есть лучшие инструменты для этого, а именно репозитории кода (git, mercurial, svn...) или теперь блокировка файлов.

Чтобы закрепить версии вашего пакета, вы можете использовать:

• Вариант 1. Используйте более новую версию 5 NPM, которая поставляется с узлом 8. Он использует package-lock.json файл (см. блог узла и выпуск узла 8)

• Вариант 2: использовать пряжу вместо npm, Это менеджер пакетов из Facebook, быстрее, чем npm и он использует yarn.lockфайл. Он использует то же самоеpackage.jsonиначе.

Это сопоставимо с файлами блокировки в других менеджерах пакетов, таких как Bundler или Cargo. Он похож на npm-shrinkwrap.json, но не с потерями и создает воспроизводимые результаты.

npmна самом деле скопировал эту функцию изyarn, среди прочего.

• Вариант 3: это был ранее рекомендуемый подход, который я больше не рекомендую. Идея заключалась в использованииnpm shrinkwrapбольшую часть времени, а иногда и помещать все это, включая папку node_module, в ваш репозиторий кода. Или, возможно, использовать термоусадочную упаковку. Лучшие практики того времени обсуждались в блоге node.js и на радостных сайтах разработчиков.

Смотрите также

Это немного выходит за рамки вопроса, но я бы хотел упомянуть последний тип зависимостей (о которых я знаю): зависимости между равноправными узлами. Также см. Этот связанный вопрос SO и, возможно, документы yarn на связанных зависимостях.

Answer 3

Другое преимущество заключается в том, что вы можете поместить свои внутренние зависимости (компоненты приложения) и затем просто требовать их в своем приложении, как если бы они были независимыми модулями, вместо того, чтобы загромождать вашу lib/ и публиковать их в npm.

Если / когда они созрели до такой степени, что могли бы жить как отдельные модули, вы можете легко поместить их в npm, не изменяя свой код.

Answer 4

Я удивлен, что не видел это здесь уже, но когда тщательно отобран, bundledDependencies может быть использован для создания распространяемого пакета из npm pack который будет работать в системе, где npm не настроен. Это полезно, если у вас есть, например, система, которая не подключена к сети / не подключена к Интернету: перенесите пакет на флэш-накопитель (или еще что-нибудь) и распакуйте архив, а затем npm run или же node index.js и это просто работает.

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

Answer 5

Предположим, вы используете pnpm для управления монорепозиторием и у вас есть папка utils. Чтобы получить доступ к этой папке, вы можете выполнить одно из следующих действий (последний вариант использует ):

• Используйте относительный импорт, который может в конечном итоге выглядеть уродливо, сбивать с толку, нарушать инкапсуляцию и даже может сломаться, если вы когда-нибудь измените расположение папки без обновления импорта.
• В качестве более удобного варианта, если вы используете TypeScript, вы можете назначить псевдоним пути к папке utils любое имя, например «utils». В результате каждому дочернему пакету нужно будет ссылаться только на псевдоним, и если вы когда-нибудь измените расположение папки utils, вам нужно будет изменить только путь в файле . НО, это сломается, если вы определите другойtsconfig.jsonв дочернем пакете , который также использует «пути» (опция псевдонима)
• Вы можете использовать для поддержки частного и локального пакета утилит, который пользователи никогда не смогут загрузить из npm, но вы все равно сможете использовать их в своих общедоступных пакетах. Таким образом, вы также сможете ссылаться на него по имени, а не по относительному пути.

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

Answer 6

С оперативной точки зрения я смотрю на bundledDependencies как хранилище закрытых модулей модуля, где зависимости более общедоступны, разрешены между вашим модулем и его зависимостями (и подчиненными зависимостями). Ваш модуль может полагаться на более старую версию, скажем, реакции, но зависимость требует самой последней и самой лучшей. Ваш пакет / установка приведет к вашей закрепленной версии в node_modules/$yourmodule/node_modules/reactв то время как ваша зависимость получит свою версию в node_modules/react (или же node_modules/$dependency/node_modules/react если они так склонны).

Предупреждение: я недавно столкнулся с зависимостью, которая неправильно настраивала свою зависимость от реакции, и наличие реакции в bundledDependencies вызвало сбой этого зависимого модуля во время выполнения.