Зависимости JavaScript: все, что вы хотели знать, но боялись спросить

Полное руководство по пяти типам зависимостей. Каждый, кто когда-либо использовал NPM, знает о зависимостях normal и dev. А вот остальные менее популярны, хотя могут очень пригодиться.

Независимо от того, работаете вы бэкенд-разработчиком на Node.js или фронтенд-разработчиком и используете Node.js только для сборки проекта, вы сталкивались с концепцией зависимостей. Почему их именно пять типов, а не два, как вы, возможно, привыкли думать? В каких случаях каждый из них использовать? На эти вопросы ответил один из популярных авторов на блог-платформе Medium Фернандо Дольо (Fernando Doglio).

Normal (runtime) dependencies

Нормальные зависимости — это те, которые перечислены в “dependencies”в файле package.json. Обычно они указывают только название (для ключа) и версию (значение), а затем NPM (или любой другой менеджер пакетов) берет их из глобального реестра (на npmjs.org).

Однако это еще не все. Вместо точного номера версии вашей зависимости можно указать:

• Примерную версию. Можно воспользоваться обычными операторами сравнения, чтобы указать версии, большие, чем один конкретный номер (например >1.2.0), любую версию, меньшую или равную другому числу (например, <=1.2.0), а также можно поиграть с любой из их комбинаций (>=, >, <). Можно указать версию, эквивалентную другой, используя оператор ~ перед номером версии (например, "lodash": "~1.2.2”, который будет загружать что-либо между 1.2.2 и 1.3.0 или, другими словами, только патчи — последнее число в номере версии) . А также можно указать “совместимую” версию с указанным номером (например, “lodash”: “^ 1.2.0”, который будет загружать все совместимые версии, не включающие критические изменения или отсутствующие функции ).
• URL-адрес. Можно даже не указывать версию, а напрямую ссылаться на конкретный URL, загружая этот модуль из другого места (например, с GitHub или напрямую).
• Локальный файл. Можно напрямую ссылаться на один из ваших локальных файлов. Это удобно, если вы разрабатываете модуль и хотите протестировать его в проекте, прежде чем выпустить в NPM. С помощью параметра локального файла можно создать ссылку на папку локального модуля. Можно использовать как полные, так и частичные пути, если перед ними стоит префикс file://.

Когда использовать нормальную зависимость?

Обычные зависимости содержат все, что требуется проекту для работы в продакшене и не представлено ни одним другим модулем.

Но если сам ваш проект — это модуль, появляется один нюанс. Если ваш модуль предназначен для использования с другими пакетами, такими как React или Babel, их не нужно включать в зависимости, поскольку подразумевается, что они уже присутствуют.

Peer dependencies

Одноранговые зависимости указывает на зависимость (или совместимость), но не требуют скачивать код модуля. Этот тип зависимости подходит для случаев, когда для модуля нужна зависимость, уже используемая в корневом проекте, чтобы менеджер пакетов не скачивал ее повторно, а подключал уже скачанную. 

Примеры использования peerDependencies:

• Плагин для Babel
• Пакеты express middleware
• Micro Frontend
• Bit-компонент

Например, возьмем этот React-компонент:

Это простая кнопка; если на нее нажать, она остается выбранной, пока на нее не нажмешь еще раз.

Если посмотреть на код в ее файле package.json, мы увидим, что все ее зависимости записаны в peerDependencies:

У нее нет прямых зависимостей, но без React.js она не сможет работать. Понятно, что использовать ее будут именно в проекте на React, а использование одноранговой зависимости существенно “облегчит вес” кода самой кнопки.

Dev Dependencies

Название говорит само за себя: devDependencies содержат модули, используемые только в процессе разработки. Например линтеры, документацию и т.д.

Все, что не будет использоваться в продакшене, — это зависимости для разработки.

Зависимости для разработки загружаются только по команде npm install или npm link из корневой папки проекта. То есть при разворачивания проекта внутри другого, менеджер будет игнорировать все модули из devDependencies.

Как использовать?

Все зависимости, которые не будут использоваться после разверстки проекта, желательно записывать в devDependencies.

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

Bundled Dependencies

Они используются, если вы хотите превратить свой проект в один файл. Команда npm pack превращает папку с проектом в единый архив.

Зависимости, которые вы хотите, чтобы упаковщик добавил в архив, нужно записать в массив bundledDependencies(кстати bundleDependencies тоже сработает).

{
...
   "dependencies": {
    "lodash": "1.0.2",
    "request": "4.0.1"
  },
  "bundledDependencies": ["lodash"]
...
}

 

Рассмотрим фрагмент файла package.json, показанный выше. После команды npm pack на выходе вы получите архивный файл, содержащий также и модуль lodash.

Это функция полезна в тех случаях, когда вам необходимо распространить ваш пакет  одним файлом (помните, что можно указать URL-адрес или локальный путь, как и в нормальной зависимости).

Optional dependencies

Ну и наконец последний тип зависимостей — точно такой же, как и нормальный, за исключением одной вещи: 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, чтобы пропустить опциональные зависимости.