Каждый JS-разработчик, кто хоть раз использовал NPM, знает как минимум про два типа зависимостей — normal и dev. Несмотря на то, что остальные не пользуются такой высокой популярностью, на практике они могут стать незаменимыми. Поэтому важно не просто знать об их существовании, но также уметь правильно и своевременно применять. Как именно — разбираемся в этой статье.
Все normal или runtime зависимости JavaScript перечислены в dependencies, в папке package.json. Как правило они указывают только название ключа и версию (значение), после чего менеджер пакетов, например это может быть NPM — берет их из глобального реестра.
При этом указывать точную версию зависимости совершенно не обязательно, вместо этого вы можете установить:
В обычных зависимостях содержится все, что необходимо для разработки проекта и не представлено ни одним из существующих модулей. Однако, если ваш проект — это и есть модуль, тут возникает нюанс — при использовании такого модуля в других пакетах, например таких как React, включать его в зависимости не нужно. В таком случае подразумевается, что она уже присутствует.
Указывают на зависимость или совместимость, однако не требуют скачивания кода модуля. Такой тип используются в случаях, когда модулю нужна зависимость, которая уже используется в корневом проекте, и скачивать ее заново не имеет смысла. Вместо этого менеджер пакетов подключает уже существующую.
Приведем несколько примеров использования peerDependencies:
Содержит пакеты, которые нужны разработчику в процессе продакшена. Например, это могут быть линтеры, документация и прочее. В то же время все модули, которые не будут использованы во время создания проекта — являются зависимостями для разработки.
Такие зависимости загружаются из корневой папки проекта с помощью команд npm install или npm link. Соответственно, при развертывании одного проекта внутри другого, менеджер пакетов будет игнорировать модули из devDependencies.
Зависимости, неиспользованные в ходе создания проекта настоятельно рекомендуется записывать в devDependencies. Это крайне полезно, особенно если вы разрабатываете модуль, который будет использоваться в сторонних проектах.
Основное преимущество использования зависимостей разработки заключается в том, что в процессе развертывания проекта менеджер пакетов загрузит только его собственные devDependencies, а не всех модулей которые были к нему подключены.
Такой тип используется в случаях, когда проект нужно преобразовать в один файл. Использовав команду npm pack, вы превратите папку с проектом в целостный архив, а чтобы упаковщик понял, какие зависимости вы хотите в него добавить, нужно записать массив bundledDependencies или bundleDependencies.
Эта функция очень удобна в случаях, когда нужно распространить проект — вы просто формируете единый архив и отправляете получателю
Пятый тип зависимости в целом схож с Normal dependencies, но с одним существенным отличием — менеджер пакетов не выдает ошибку, если не может их загрузить.
На практике это выглядит следующим образом: если после запуска команды npm install процесс по какой-либо причине не может установить зависимости — нет интернет-соединения, не обнаружен файл и прочее, optional dependencies не мешают менеджеру продолжить работу. В той же ситуации, при использовании нормальных зависимостей, мы получили бы ошибку, и установка была бы отменена.
Однако, в таком случае разработчику важно отладить процесс и убедиться, что код будет корректно работать в случае отсутствия зависимостей.
У этого типа есть еще один любопытный вариант применения — инсталляция необязательных зависимостей. Дело в том, что при разработке проектов некоторые системные зависимости могут быть опциональными.
В качестве примера приведем совместимость с платформой CI, которую можно устанавливать только в случае использования этой платформы, а в других случаях — игнорировать.
В подобных ситуациях, при использовании полного перечня зависимостей вы можете выполнять обычную установку NPM, а затем с помощью команды npm install --no-optional пропускать опциональные, что положительно скажется на быстродействии кода.
