Задать вопрос
johnymkp
@johnymkp

Чем технически отличаются dev-, prod- и peer-зависимости в Node JS?

Прочитав много статей и вопросов с ответами, я вроде бы понял что к чему, но хочу уточнить некоторые моменты. Итак:

dev-зависимости
это зависимости, нужные чтобы разрабатывать пакет, тестировать его, билдить и т.д. Пример dev-зависимости - это typescript-компилятор. Очевидно, что после компиляции он становится не нужен - пакет сможет работать и без него.

prod-зависимости
это зависимости, нужные пакету уже в процессе его работы. Например, если он пользуется axios для работы с http-запросами, то если вместе с этим пакетом не поставить axios, то пакет работать не сможет.

peer-зависимости
это зависимости, которые просто требуются пакету для чего либо. Пир-зависимость может быть нужна и на этапе разработки, и в процессе работы. Т.е. концептуально пир-зависимость не имеет такого четкого назначения как dev и prod. Пир-зависимость, скорее, выделяется чисто технически - она не является частью пакета (хотя он в ней нуждается) и устанавливается "параллельно" с ним.


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

Для наглядности: пусть у нас есть пакет Fake, а у него такие зависимости:
* dev: dev1, dev2
* prod: prod1, prod2
* peer: peer1

У нас всего два сценария пользования Fake'ом:
1) просто пользоваться

Если мы хотим просто пользоваться пакетом Fake, т.е. устанавливаем его как `npm i fake`, то нам установятся также prod1, prod2 и peer1. Причем структура получится примерно такая:
/ корневая директория нашего проекта
  package.json
  /node_modules
      /fake
          package.json
          /node_modules
              /prod1  - прод-зависимости пакета Fake установились как "его часть", внутрь его собственной папки модулей.
              /prod2
      /peer1  - пир-зависимость пакета Fake установилась "параллельно" с ним, в папку модулей "клиента"


2) дебажить, дорабатывать

Если мы хотим "дебажить-дорабатывать" пакет Fake, то мы скачиваем исходники и из его корня вызываем `npm install`. В этом случае нам устанавливаются всего его зависимости - и prod, и peer, и dev:
/ корневая директория нашего проекта
  package.json
  /node_modules
      /fake
          package.json
          /node_modules
              /prod1
              /prod2
              /dev1  - dev-зависимости тоже поставились как часть пакета Fake
              /dev2
      /peer1


Таким образом получаются такие выводы:
* Деление зависимостей на dev и prod - это просто условность, чтобы не тянуть лишние зависимости. Мы могли бы объявить все зависимости как prod и все бы так же работало, просто занимало бы больше месте на диске.
* peer-зависимости - обычно предназначены для подключения особо крупных библиотек, вроде react (типичный пример, приводимый в интернете без толкового объяснения, почему), когда предполагается, что множество более мелких библиотек будут пользоваться одной и той же версией этой крупной библиотеки. Теоретически, мы могли бы отмечать и мелкие библиотеки как peer-зависимости, но это (вероятно) дало бы лишнюю нагрузку за счет необходимости анализировать версии зависимостей (т.к. проще, когда каждая библиотека просто тащит мелочовку вроде axios нужных версий к себе и получается меньше потенциальных конфликтов версий).

Вопрос получился большой, возможно даже на мини-статью тянет. Я составил его потому, что везде, где я на эту тему читал, были какие-то недомолвки, которые я попытался закрыть. Кому не лень, почитайте и напишите, где я ошибся или мб сможете добавить каких-то деталей.
  • Вопрос задан
  • 190 просмотров
Подписаться 2 Средний 2 комментария
Решения вопроса 1
peer-зависимости - обычно предназначены для подключения особо крупных библиотек
Крупность тут ни при чём. Peer-зависимости нужны для реализациии чего-то типа плагинов - они позволяют этому самому плагину сказать "я работают в такой-то библиотеке такой-то версии, но сама эта библиотека в моём коде не используется". Таким образом при установке плагина проверяется, что на одном с ним уровне есть эта библиотека, но в зависимости плагина она не тянется.

Теоретически, мы могли бы отмечать и мелкие библиотеки как peer-зависимости.
Peer-зависимости вообще не используются в конечных приложениях, они нужны только для библиотек, которые сами будут распространяться как пакеты. А у таких библиотек не может быть много peer-зависимостей по определению.

Ну и вообще-то не особо понятно, в чём конкретно у вас вопрос.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы