Вопрос: В чем разница между зависимостями, devDependencies и peerDependencies в файле npm package.json?


Эта документация очень плохо отвечает на мой вопрос. Я не понял этих объяснений. Может ли кто-нибудь сказать более простые слова? Может быть, с примерами, если трудно выбрать простые слова?


1419


источник


Ответы:


Резюме важных различий в поведении:

  • dependenciesустановлены на обоих:

    • npm installиз каталога, содержащего package.json
    • npm install $packageв любом другом каталоге
  • devDependenciesнаходятся:

    • также установлен на npm installв каталоге, который содержит package.json, если вы не передадите --productionфлаг (go upvote Ответ Гаяна Харита ).
    • не установлен npm install "$package"в любом другом каталоге, если вы не --devвариант.
    • не установлены транзитивно.
  • peerDependencies:

    • до 3.0: всегда устанавливаются, если они отсутствуют, и вызывают ошибку, если различные несовместимые версии зависимостей будут использоваться разными зависимостями.
    • ожидается начиная с 3,0 (непроверенный): дать предупреждение, если отсутствует npm install, и вам нужно самостоятельно самостоятельно решить проблему. При запуске, если отсутствует зависимость, вы получаете сообщение об ошибке (упомянутое @nextgentech )
  • Транзитивность (упоминается Бен Хатчисон ):

    • dependenciesустанавливаются транзитивно: если A требует B, а B требует C, то C устанавливается, иначе B не может работать, и ни один из них не будет A.

    • devDependenciesне установлены транзитивно. Например. нам не нужно тестировать B для тестирования A, поэтому зависимости B от тестирования могут быть исключены.

Связанные с этим варианты не обсуждаются здесь:

devDependencies

dependenciesдолжны выполняться, devDependenciesтолько для разработки, например: модульные тесты, Coffeescript для трансляции, Javascript, ...

Если вы собираетесь разработать пакет, вы его загружаете (например, через git clone), перейдите к его корню, который содержит package.json, и выполните:

npm install

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

Если, однако, вы только конечный пользователь, который просто хочет установить пакет для его использования, вы будете делать из любого каталога:

npm install "$package"

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

Если вы действительно хотите установить пакеты разработки в этом случае, вы можете установить devconfig для true, возможно из командной строки:

npm install "$package" --dev

Этот вариант falseпо умолчанию, поскольку это гораздо менее распространенный случай.

peerDependencies

(проверено до 3.0)

Источник: https://nodejs.org/en/blog/npm/peer-dependencies/

С регулярными зависимостями вы можете иметь несколько версий зависимости: она просто устанавливается внутри node_modulesзависимости.

Например. если dependency1а также dependency2оба зависят от dependency3в разных версиях дерево проекта будет выглядеть так:

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

Однако плагины - это пакеты, которые обычно не требуют другого пакета, который называется хозяин в данном контексте. Вместо:

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

Например. если dependency1а также dependency2равный dependency3, дерево проекта будет выглядеть так:

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

Это происходит, хотя вы никогда не упоминаете dependency3в вашей package.jsonфайл.

Я думаю, что это пример Инверсия контроля дизайн рисунок.

Прототипным примером одноранговых зависимостей является Grunt, хост и его плагины.

Например, в плагине Grunt, например https://github.com/gruntjs/grunt-contrib-uglify , вы увидите, что:

  • gruntэто peerDependency
  • единственный require('grunt')находится под tests/: он фактически не используется программой.

Затем, когда пользователь будет использовать плагин, он будет неявно требовать от плагина Gruntfileдобавив grunt.loadNpmTasks('grunt-contrib-uglify')линии, но это gruntчто пользователь будет звонить напрямую.

Тогда это не сработает, если для каждого плагина требуется другая версия Grunt.

Руководство

Я думаю, что док отвечает на вопрос достаточно хорошо, возможно, вы недостаточно знакомы с менеджерами узлов и других пакетов. Я, наверное, понимаю это только потому, что знаю немного о пакете Ruby.

Ключевая строка:

Эти вещи будут установлены при установке npm-ссылки или npm-установки из корня пакета и могут управляться, как и любой другой параметр конфигурации npm. Подробнее см. В разделе npm-config (7).

А затем под npm-config (7) найдите dev:

Default: false
Type: Boolean

Install dev-dependencies along with packages.

1697



Если вы не хотите устанавливать devDependencies, вы просто можете использовать npm install --production


347



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


89



Чтобы сохранить пакет для package.json как зависимости dev:

npm install "$package" --save-dev

Когда вы запускаете npm installон установит оба devDependenciesа также dependencies, Чтобы избежать установки devDependenciesбег:

npm install --production

47



Существуют некоторые модули и пакеты, необходимые только для разработки, которые не нужны в производстве. Как говорится в документация :

Если кто-то планирует загрузить и использовать ваш модуль в своей программе, то, вероятно, они не хотят или не должны загружать и создавать внешние тестовые или документационные рамки, которые вы используете. В этом случае лучше всего перечислить эти дополнительные элементы в хэше dev.


29



зависимости
Зависимости, которые должен выполнять ваш проект, например библиотека, предоставляющая функции, которые вы вызываете из своего кода.
Они установлены транзитивно (если A зависит от B, зависит от C, npm install на A будет устанавливать B и C).
Пример: lodash: ваш проект вызывает некоторые функции lodash.

devDependencies
Зависимости, которые вам нужны только во время разработки или выпуска, например, компиляторы, которые принимают ваш код и компилируют его в javascript, тестовые среды или генераторы документации.
Они не установлены транзитивно (если A зависит от B dev - зависит от C, npm install на A будет устанавливать только B).
Пример: grunt: ваш проект использует grunt для создания самого себя.

peerDependencies
Зависимости, которые ваш проект подключает или изменяет в родительском проекте, обычно является плагином для какой-либо другой библиотеки или инструмента. Он просто предназначен для проверки, чтобы родительский проект (проект, который будет зависеть от вашего проекта) зависит от проекта, в который вы входите. Поэтому, если вы создадите плагин C, который добавит функциональность библиотеке B, тогда у кого-то, у кого будет проект A, потребуется зависимость от B, если у них есть зависимость от C.
Они не установлены (если npm <3), они проверяются только.
Пример: grunt: ваш проект добавляет функциональность для ворчания и может использоваться только для проектов, которые используют grunt.

В этой документации очень хорошо объясняются зависимости между сверстниками: https://nodejs.org/en/blog/npm/peer-dependencies/

Кроме того, документация npm со временем улучшилась и теперь имеет более подробные объяснения различных типов зависимостей: https://github.com/npm/npm/blob/master/doc/files/package.json.md#devdependencies


15



A simple explanation that made it more clear to me is:

When you deploy your app, modules in dependencies need to be installed or your app won't work. Modules in devDependencies don't need to be installed on the production server since you're not developing on that machine. link


7



I'd like to add to the answer my view on these dependencies explanations

  • dependencies are used for direct usage in your codebase, things that usually end up in the production code, or chunks of code
  • devDependencies are used for the build process, tools that help you manage how the end code will end up, third party test modules, (ex. webpack stuff)

4