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

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

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

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

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

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

Что делают bundledDependencies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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