Прочитав много статей и вопросов с ответами, я вроде бы понял что к чему, но хочу уточнить некоторые моменты. Итак:
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 нужных версий к себе и получается меньше потенциальных конфликтов версий).
Вопрос получился большой, возможно даже на мини-статью тянет. Я составил его потому, что везде, где я на эту тему читал, были какие-то недомолвки, которые я попытался закрыть. Кому не лень, почитайте и напишите, где я ошибся или мб сможете добавить каких-то деталей.
