Полное руководство по пяти типам зависимостей. Каждый, кто когда-либо использовал NPM, знает о зависимостях normal и dev. А вот остальные менее популярны, хотя могут очень пригодиться.
Независимо от того, работаете вы бэкенд-разработчиком на Node.js или фронтенд-разработчиком и используете Node.js только для сборки проекта, вы сталкивались с концепцией зависимостей. Почему их именно пять типов, а не два, как вы, возможно, привыкли думать? В каких случаях каждый из них использовать? На эти вопросы ответил один из популярных авторов на блог-платформе Medium Фернандо Дольо (Fernando Doglio).
Нормальные зависимости — это те, которые перечислены в “dependencies”
в файле package.json
. Обычно они указывают только название (для ключа) и версию (значение), а затем NPM (или любой другой менеджер пакетов) берет их из глобального реестра (на npmjs.org).
Однако это еще не все. Вместо точного номера версии вашей зависимости можно указать:
"lodash": "~1.2.2”
, который будет загружать что-либо между 1.2.2 и 1.3.0 или, другими словами, только патчи — последнее число в номере версии) . А также можно указать “совместимую” версию с указанным номером (например, “lodash”: “^ 1.2.0”
, который будет загружать все совместимые версии, не включающие критические изменения или отсутствующие функции ).file://
.Когда использовать нормальную зависимость?
Обычные зависимости содержат все, что требуется проекту для работы в продакшене и не представлено ни одним другим модулем.
Но если сам ваш проект — это модуль, появляется один нюанс. Если ваш модуль предназначен для использования с другими пакетами, такими как React или Babel, их не нужно включать в зависимости, поскольку подразумевается, что они уже присутствуют.
Одноранговые зависимости указывает на зависимость (или совместимость), но не требуют скачивать код модуля. Этот тип зависимости подходит для случаев, когда для модуля нужна зависимость, уже используемая в корневом проекте, чтобы менеджер пакетов не скачивал ее повторно, а подключал уже скачанную.
Примеры использования peerDependencies
:
Например, возьмем этот React-компонент:
Это простая кнопка; если на нее нажать, она остается выбранной, пока на нее не нажмешь еще раз.
Если посмотреть на код в ее файле package.json
, мы увидим, что все ее зависимости записаны в peerDependencies
:
У нее нет прямых зависимостей, но без React.js она не сможет работать. Понятно, что использовать ее будут именно в проекте на React, а использование одноранговой зависимости существенно “облегчит вес” кода самой кнопки.
Название говорит само за себя: devDependencies
содержат модули, используемые только в процессе разработки. Например линтеры, документацию и т.д.
Все, что не будет использоваться в продакшене, — это зависимости для разработки.
Зависимости для разработки загружаются только по команде npm install или npm link из корневой папки проекта. То есть при разворачивания проекта внутри другого, менеджер будет игнорировать все модули из devDependencies
.
Как использовать?
Все зависимости, которые не будут использоваться после разверстки проекта, желательно записывать в devDependencies
.
Это тем более полезно, если вы пишите модуль, который будет использоваться в других проектах. Преимущества этого подхода в том, что разворачивая проект, менеджер пакетов установит только его личные devDependencies
, а не всех подключенных к нему модулей.
Они используются, если вы хотите превратить свой проект в один файл. Команда npm pack превращает папку с проектом в единый архив.
Зависимости, которые вы хотите, чтобы упаковщик добавил в архив, нужно записать в массив bundledDependencies
(кстати bundleDependencies
тоже сработает).
{ ... "dependencies": { "lodash": "1.0.2", "request": "4.0.1" }, "bundledDependencies": ["lodash"] ... }
Рассмотрим фрагмент файла package.json
, показанный выше. После команды npm pack на выходе вы получите архивный файл, содержащий также и модуль lodash.
Это функция полезна в тех случаях, когда вам необходимо распространить ваш пакет одним файлом (помните, что можно указать URL-адрес или локальный путь, как и в нормальной зависимости).
Ну и наконец последний тип зависимостей — точно такой же, как и нормальный, за исключением одной вещи: NPM не выдает ошибку, если не может их загрузить. Обычно, если после команды npm install процесс не может установить зависимость по любой причине (отсутствие интернет-подключения, не может найти файл, версию и т.д.), то отменяет установку и выдает ошибку. Опциональные зависимости вместо этого разрешают менеджеру продолжать работу. Конечно, на разработчике лежит ответственность отладить процесс в случае отсутствующих зависимостей, например так:
let foo = null; try { foo = require("foo-dep"); } catch (e) { foo = require("./local-polyfill") } //... use foo from here on out
Когда использовать опциональные зависимости?
Когда вы ссылаетесь на ненадежный источник. Только убедитесь в работоспособности кода при отсутствующей зависимости.
Другой интересный вариант использования — установка необязательных зависимостей. Иногда у вас могут быть некоторые системные зависимости, например совместимость с платформой CI, которые можно установить при использовании платформы и игнорировать, если не собираетесь ее использовать.
В таких ситуациях можно использовать обычную установку npm, когда используете полный набор зависимостей, а затем использовать npm install --no-optional
, чтобы пропустить опциональные зависимости.
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…