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


85

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

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


16
«Если это написано« bundleDependencies », то это тоже почетно». Отличная документация!
Colonel Panic

10
И тем не менее, почему-то печально фиксировать его, чтобы просто читать «тоже почетно». В затруднительном положении, если бы я приказал самураю или рыцарю на помощь, я бы определенно хотел, чтобы он пришел в комплекте с совместимым оружием и доспехами - и был бы честен.
Джон Кумбс,

3
«Я думаю, если мы хотим быть абсолютно уверены, что получим правильную версию, даже если модуль, на который мы ссылаемся,
joews

Ответы:


49

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

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

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


1
Как он всегда обеспечивает правильные зависимости? Означает ли это, что npm updateэто не повлияет на какие-либо зависимости в bundledDependencies?
Кевин Гадьяни

2
Да исправить. Обратите внимание, что связанные зависимости могут быть «неправильными» ни в каком фундаментальном смысле. Они как раз то, что сказал человек, занимающийся сборкой, был правильным.
Джулиан Найт

7
Может быть, потому, что вы смотрите на ответ, которому пять с половиной лет ! Объем, который Node.JS продвинулся за это время, феноменален. Возможно, вы вместо этого хотели бы добавить что-нибудь полезное в качестве комментария?
Джулиан Найт,

105

Для быстрого читателя : это ОК идет о 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 .


6
«включая папку node_module» - это довольно странная вещь, которая загрязняет ваше репо сгенерированным кодом ... особенно когда вы работаете с нативными модулями ...
Александр

@Olexandr Между этим и риском, что пакет сломает ваше приложение, я думаю, выбор прост. Обратите внимание, что вы можете поместить в отдельную ветку (например, если используете git). Согласитесь, это далеко не идеальное решение.
nha

3
Я бы не рекомендовал проверять node_modules из-за, например, пакетов, таких как phantomjs, которые устанавливают соответствующий двоичный файл для текущей системы. Это означает, что если один разработчик запускает npm install в Linux и проверяет node_modules - это не сработает для другого разработчика, который клонирует репо в Windows. Лучше проверить архивы, в которых npm install загрузок, и указать на них npm-shrinkwrap.json. Вы можете автоматизировать этот процесс с помощью npm install -g shrinkpackинструмента.
Джейми Мейсон

1
Спасибо @nha, вы также будете защищены от этого с помощью shrinkpack, поскольку архивы реестра будут в репозитории вашего проекта.
Джейми Мейсон

1
@fold_left Да, действительно, спасибо за указание (и за создание термоусадочной упаковки). Я просто сказал, что всего этого можно было бы избежать, если бы реестр npm действовал как неизменное хранилище данных.
nha

22

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

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


3

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

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


0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.