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

вопрос создан в Fri, Oct 26, 2018 12:00 AM

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

РЕДАКТИРОВАТЬ также добавил peerDependencies, что тесно связано и может привести к путанице.

    
1753
  1. Обратите внимание, что есть также optionalDependencies сейчас.
    2016-06-04 18: 50: 00Z
  2. @ AidanFeldman "AdditionalDependencies" - мой оксюморон дня
    2018-03-19 15: 56: 58Z
11 ответов                              11                         

Сводка важных различий в поведении:

  • установлены dependencies как:

    •  npm install из каталога, который содержит package.json
    •  npm install $package в любом другом каталоге
  • devDependencies : /р>

    • также установлен на npm install в каталоге, содержащем package.json, если вы не передадите флаг --production (перейдите на страницу ответ Гаян Чарит ).
    • не установлен на 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.

Если вы действительно хотите установить пакеты разработки в этом случае, вы можете установить для параметра конфигурации dev значение 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/

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

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

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

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

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

Я думаю, что это экземпляр шаблона дизайна Inversion of Control .

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

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

  •  grunt - это peer-dependency
  • только require('grunt') меньше tests/: он фактически не используется программой.

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

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

Руководство

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

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

  

Эти вещи будут установлены при выполнении npm link или npm install из корня пакета и могут управляться как любой другой параметр конфигурации npm. См. Npm-config (7) для получения дополнительной информации по этой теме.

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

 
Default: false
Type: Boolean

Install dev-dependencies along with packages.
    
2076
2018-12-07 14: 32: 44Z
  1. Ах. Я вижу, я неправильно понял. Ваш ответ звучит так, как будто npm install package - это команда, которую вы будете использовать для установки всех пакетов, которые не являются dev-зависимостями, а не то, что, как я теперь думаю, вы имели в виду, а именно: «установите пакет с именем [package]», как я и думал работал, прежде чем читать это. Если бы я был тобой, я бы отредактировал, чтобы сказать [имя-пакета], что ясно показывает, что ты имеешь в виду «вставить-имя-здесь».
    2014-03-18 12: 39: 43Z
  2. Это здорово! Я так и не понял, но этот ответ научил меня тому, что разница между зависимостями и devDependencies применима только в том случае, если вы собираетесь опубликовать пакет npm. Если вы просто работаете над приложением или сайтом, это не должно иметь большого значения. Спасибо!
    2014-08-29 03: 37: 59Z
  3. Это сообщение следует обновить, чтобы отразить измененное поведение peerDependencies в предстоящем npm @ 3. Из blog.npmjs.org/post/110924823920/npm-weekly-5: "Мы больше не будем автоматически загружать зависимость от однорангового узла. Вместо этого мы будем предупреждать вас, если зависимость от однорангового узла еще не установлена. Это требует от вас разрешения конфликтов peerDependency самостоятельно, вручную, но в долгосрочной перспективе это должно снизить вероятность того, что вы окажетесь в затруднительном положении с зависимостями ваших пакетов. "
    2015-05-22 04: 11: 27Z
  4. Кроме того, devDependencies не устанавливаются транзитивно зависимыми пакетами. Пример: пакет A зависит от пакета B. Пакет B зависит от пакета C, а B также devDepends для пакета D. Если вы запустите npm install из пакета A, вы получите B и C, но не D.
    2016-01-23 05: 31: 24Z
  5. Важно отметить, что devDependencies не установлены, когда NODE_ENV установлен на production.
    2018-08-04 19: 23: 03Z

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

    
431
2018-12-15 03: 31: 20Z
  1. npm install --save для программной зависимости?
    2015-07-27 09: 50: 49Z
  2. Установка npm установит все зависимости. Флаг --save используется, когда вы хотите добавить определенный модуль также в package.json. Например: - npm install uglify --save установит uglify в папку вашего проекта и добавит uglify в файл project, package.json.
    2015-09-13 07: 58: 37Z
  3. И поскольку мы говорим о devDependencies, вы можете использовать --save-dev, чтобы сохранить новый модуль как devDependency. Пример: npm install uglify --save-dev
    2016-09-29 18: 39: 53Z
  4. Начиная с npm 5, опция --save больше не нужна. Если вы выполните «npm install my-package», он добавит my-package в качестве зависимости в ваш файл package.json.
    2018-02-23 22: 58: 22Z
  5. просто npm install
    2019-01-11 14: 46: 12Z

В качестве примера, mocha обычно представляет собой devDependency, так как тестирование не требуется в производственной среде, тогда как express будет зависимостью.

    
101
2013-09-18 18: 39: 54Z
  1. Я бы предпочел поставить тестирование в качестве зависимости, так как вы можете запустить самопроверку перед запуском производственного сервера
    2014-01-10 22: 08: 04Z
  2. Я бы вместо этого рекомендовал использовать сервис непрерывной интеграции, такой как Hudson или CircleCI, который запускает ваши тесты и затем развертывается в рабочем режиме, если они пройдут.
    2014-01-12 13: 57: 16Z
  3. Тем не менее может быть уместно протестировать фактический сервер, поскольку сервер CI может несколько отличаться от сервера prod, и это различие может, например, запретить запуск приложения ...
    2016-03-25 22: 33: 49Z
  4. @ Николь, почему бы вам сделать ваш промежуточный сервер по конфигурации не идентичным вашему продукту?
    2017-11-20 15: 57: 52Z
  5. @ Lucas, например. промежуточный сервер обычно имеет другую БД и находится в другом сегменте сети, нежели компьютер prod. Любое из них может быть потенциальной причиной отказа. (Конечно, зависит от ваших конкретных настроек и требований.)
    2017-11-20 19: 54: 17Z

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

 
npm install "$package" --save-dev

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

 
npm install --production
    
58
2018-04-23 10: 36: 11Z
  1. вы также можете использовать: npm i -S
    2017-07-28 22: 00: 31Z

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

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

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

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

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

    
46
2019-01-29 21: 36: 29Z
  1. Лучшее объяснение peerDependencies в этой теме
    2018-10-10 14: 55: 26Z
  2. Эта ссылка сейчас не работает: github.com/npm/npm/blob/master/doc/files/…
    2019-01-24 09: 48: 34Z
  3. @ Исправлено HimanshuAggarwal. Спасибо, что обратили внимание.
    2019-01-29 21: 36: 49Z

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

  

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

    
33
2013-09-18 14: 59: 46Z
  1. Что если вы используете только файл bundle.js на производстве? вам действительно нужны эти зависимости?
    2018-09-24 18: 07: 51Z
  2. Если вы запускаете bundle.js на сервере, вы делаете веб-пакет на стороне сервера или что-то в этом роде ... Проверьте, так ли это, потому что обычно это не так и на самом деле требуется много работы, чтобы запустить его правильно (я знаю, потому что я сделал это). Я подозреваю, что ваш bundle.js просто доступен браузерам и содержит код на стороне клиента.
    2019-01-14 18: 29: 55Z

Простое объяснение, которое сделало его более понятным для меня:

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

    
12
2017-09-29 15: 36: 08Z
  1. Итак, если мы создаем веб-сайт и в версии prod все библиотеки будут встроены в vendor.js, все наши операции должны быть разработчиками, если скомпилированный код передается в репозиторий? И это должно быть зафиксировано, так как в других случаях странно, что вы должны скомпилировать модуль, а не просто установить его (и тестирование также где-то здесь, так как любое изменение в подмодулях может привести к регрессии) ...
    2017-10-02 10: 04: 30Z
  2. Отличный ответ, но есть вопрос? Возможно ли в Webpack построить поврежденную связку? Я предполагаю, что пакеты devDependencies не будут работать в версии продукта, я имею в виду webpack -p. пожалуйста, ответьте на мой вопрос.
    2017-11-29 10: 18: 24Z
  3. Если во время производственной сборки возникает какая-либо проблема, процесс развертывания должен быть спроектирован таким образом, чтобы он отображал ошибку во время сборки и не передавал поврежденный код в производство (например Вы можете попробовать Дженкинс). В любом случае, на рабочем сервере не требуется устанавливать зависимости.
    2017-12-04 16: 04: 52Z
  4. и как насчет одноранговых зависимостей?
    2019-01-28 17: 24: 42Z

Я хотел бы добавить к ответу свой взгляд на объяснения этих зависимостей

  •  dependencies используются для непосредственного использования в вашей кодовой базе, вещах, которые обычно заканчиваются в производственном коде, или фрагментам кода
  •  devDependencies используются для процесса сборки, инструменты, которые помогают вам управлять тем, как закончится конечный код, сторонние тестовые модули (например, материал webpack)
9
2018-02-16 11: 40: 18Z
  1. А как насчет ресурсов css?
    2019-03-28 01: 13: 02Z

peerDependencies для меня не имело смысла, пока я не прочитал этот фрагмент из сообщения в блоге по теме Ciro, упомянутой выше :

  

Что нужно [ плагинам ], так это способ выражения этих «зависимостей» между плагинами и их хост-пакетом. Какой-то способ сказать: «Я работаю только при подключении к версии 1.2.x моего хост-пакета, поэтому, если вы устанавливаете меня, убедитесь, что он находится рядом с совместимым хостом». Мы называем этоОтношение к сверстникам.

Плагин ожидает определенной версии хоста ...

peerDependencies - для плагинов, библиотек, которым для выполнения своих функций требуется библиотека «хост», но, возможно, они были написаны за время до того, как была выпущена последняя версия хоста.

То есть, если я напишу PluginX v1 для HostLibraryX v3 и уйду, нет гарантии, что PluginX v1 будет работать, когда будет выпущено HostLibraryX v4 (или даже HostLibraryX v3.0.1).

... но плагин не зависит от хоста ...

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

Это означает, что dependencies не совсем подходящая концепция для плагинов.

Еще хуже, если бы с моим хостом обращались как с зависимостью, мы бы оказались в такой ситуации, что в том же сообщении в блоге упоминается (немного отредактировано для использования составленного хоста и плагина этого ответа):

  

Но теперь, [если мы будем рассматривать современную версию HostLibraryX как зависимость для PluginX,] запуск npm install приводит к неожиданному графу зависимостей

 
├── HostLibraryX@4.0.0
└─┬ PluginX@1.0.0
  └── HostLibraryX@3.0.0
     

Я оставлю тонкие сбои, которые исходят от плагина с использованием API-интерфейса [HostLibraryX], отличного от основного приложения, для вашего воображения.

... и хост, очевидно, не зависит от плагина ...

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

Весь смысл плагинов заключается в том, что они могут объединяться в пару анонимно. В идеальном мире, если бы хозяин управлял ими, все было бы просто и аккуратно. опрятно, но мы не собираемся требовать библиотеки стадных кошек.

Если мы не зависимы от иерархии, может быть, мы внутризависимые коллеги ...

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

... но это не автоматические отношения.

Если я PluginX v1 и ожидаю однорангового узла (то есть имеет peerDependency ) HostLibraryX v3, я так и скажу. Если вы автоматически обновились до последней версии HostLibraryX v4 (обратите внимание, что в версии 4 ) И установлено приложение Plugin v1, вам нужно знать, верно?

npm не может справиться с этой ситуацией для меня -

  

"Эй, я вижу, вы используете PluginX v1! Я автоматически понижаю HostLibraryX с v4 до v3, кк?"

... или ...

  

"Эй, я вижу, вы используете PluginX v1. Это ожидает HostLibraryX v3, который вы оставили в пыли во время вашего последнего обновления. На всякий случай я автоматически удаляю Plugin v1 !! 1! р>

Как насчет нет, нпм ?!

Так что npm этого не делает. Он предупреждает вас о ситуации и позволяет выяснить, подходит ли HostLibraryX v4 для Plugin v1.

Coda

Хорошее управление peerDependency в плагинах сделает эту концепцию более интуитивно понятной на практике. Из сообщения блога , еще раз ...

  

Один совет: требования зависимости от сверстников, в отличие от требований для обычных зависимостей, должны быть снисходительными. Вы не должны блокировать ваши одноранговые зависимости до определенных версий исправлений. Было бы очень неприятно, если бы один плагин Chai зависел от Chai 1.4.1, а другой зависел от Chai 1.5.0, просто потому, что авторы были ленивы и не тратили время на выяснение фактической минимальной версии Chai, которой они являются. совместим с.

    
1
2018-10-11 15: 47: 38Z
  1. Понижение рейтинга без объяснения причин затрудняет решение ваших проблем. Дайте мне знать, и я постараюсь сделать вещи лучше!
    2019-03-01 18: 43: 43Z

При попытке распространить пакет npm следует избегать использования dependencies. Вместо этого вам нужно рассмотреть возможность добавления его в peerDependencies или удалить его из dependencies.

    
0
2018-07-06 12: 47: 33Z

Короче говоря

  1. Зависимости - npm install <package> save-prod пакетов instalsl, необходимых вашему приложению в производственной среде.

  2. DevDependencies - npm install <package> --save-dev установок     пакеты требуются только для локальной разработки и тестирования

  3. Просто введите npm install, чтобы установить все пакеты, упомянутые в package.json

так что если вы работаете на локальном компьютере, просто введите npm install и продолжайте:)

    
0
2019-06-07 05: 27: 25Z
источник размещен Вот