Реестр пакетов

Когда в проекте выполняют npm install, менеджер пакетов читает список зависимостей из package.json и обращается к реестру: какие версии библиотеки есть, где лежит архив, какие у неё собственные зависимости. По умолчанию это публичный реестр registry.npmjs.org. У PHP своя площадка — Packagist, откуда берёт пакеты Composer. Реестр и менеджер пакетов — разные вещи: первый хранит, второй скачивает, сверяет версии и раскладывает файлы по проекту.

Публичные и приватные реестры

Компании часто держат внутренние библиотеки — общий набор компонентов интерфейса, клиент к своему API — и не хотят выкладывать их в открытый доступ. Для этого есть приватные реестры: GitHub Packages, GitLab Package Registry, самостоятельно развёрнутый Verdaccio. Их же ставят как зеркало-кэш публичного реестра, чтобы сборка не зависела от его доступности. Какой реестр использовать для каких пакетов, указывают в файле .npmrc:

# .npmrc в корне проекта
registry=https://registry.npmjs.org/
@example:registry=https://npm.example.ru/
//npm.example.ru/:_authToken=${NPM_TOKEN}

Пакеты с префиксом @example/ пойдут во внутренний реестр, остальные — в публичный. Токен подставляется из переменной окружения и не хранится в репозитории.

Риски, о которых стоит помнить

• Похожие имена. Злоумышленники публикуют пакеты с названиями, отличающимися на букву от популярных, в расчёте на опечатку при установке.
• Подмена зависимости. Если внутренний пакет без префикса случайно запрашивают из публичного реестра, там может оказаться чужой пакет с тем же именем. Префиксы-области и явная настройка реестра закрывают эту дыру.
• Скрипты установки. Пакет может выполнить свой код прямо при установке. Поэтому новые зависимости проверяют, версии фиксируют lock-файлом, а в автоматической сборке ставят через npm ci.

Такую сборку, которая берёт пакеты из реестра на сервере, обычно запускает система непрерывной интеграции.