Ответ 1

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

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

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

Ответ 2

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

Какие связанные с этим функции зависят

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

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

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

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

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

Если не использовать связанные зависимости

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

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

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

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

Это сопоставимо с lockfiles в других менеджерах пакетов, таких как Bundler или Cargo. Это похоже на npms npm-shrinkwrap.json, однако его не lossy и создает воспроизводимые результаты.

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

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

См. также

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

Ответ 3

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

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

Ответ 4

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

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