Вы застряли на конфигурации .npmrc, потому что проекту вашей компании необходимо использовать Private Packages?

Почему все еще отображается 404 Not Found , даже если токен настроен?

Когда в компании есть несколько команд и несколько пакетов (например, @frontend, @backend), как вы можете элегантно управлять .npmrc?

Разоблачение двух мифов о .npmrc

Чтобы понять .npmrc, вам сначала нужно понять, как он работает.

Проще говоря, его основная логика сводится к двум вещам: Сопоставление области видимости (Scope Mapping) и Аутентификация (Authentication).

1. Сопоставление области видимости (Scope Mapping)

Это говорит npm: когда вы видите пакет, начинающийся с @company, не ищите его на официальном npmjs.org, а перейдите в наш указанный GitLab Registry.

@company:registry=https://gitlab.com/api/v4/groups/100/-/packages/npm/

2. Аутентификация (Authentication)

С адресом вам также нужен ключ. Ключ — это ваш AuthToken.

Вот очень важное правило: URL-адрес реестра и путь AuthToken должны «точно совпадать».

# ✅ Верно: путь точно такой же, как у реестра, определенного выше
//gitlab.com/api/v4/groups/100/-/packages/npm/:_authToken=${GITLAB_TOKEN}

# ❌ Неверно: путь не совпадает, что приведет к ошибке прав доступа
//gitlab.com/api/v4/:_authToken=${GITLAB_TOKEN}

Многие люди часто терпят неудачу при настройке из-за лишней косой черты или отсутствия уровня в пути.

Ад зависимостей и ошибки 404

Самая головная боль — это когда вы устанавливаете пакет A, который зависит от пакета B (тоже приватного), а затем npm выдает ошибку 404 Not Found.

Почему так происходит? Это происходит потому, что npm теряется при разрешении зависимостей, если нет правильного соответствия.

Особенно, когда у вас есть две разные области видимости (например, @team-a и @team-b) в разных группах GitLab, .npmrc может стать чрезвычайно сложным и трудным в поддержке. Вкупе с тем фактом, что разные реестры могут требовать разные токены, одного управления этими переменными окружения достаточно, чтобы вас насытить.

Есть ли более разумный способ?

Рекомендуемое решение: Единый реестр группы загрузки и Независимый реестр проекта публикации

Зачем это делать?

Конфигурация в действии

Вы можете скопировать этот шаблон напрямую:

Не забудьте переложить работу по защите токенов на переменные окружения, никогда не прописывайте токены прямо в коде!

# .npmrc
# Токен аутентификации уровня домена (охватывает все запросы на установку уровня группы и проекта)
//gitlab.com/:_authToken=${GITLAB_NPM_TOKEN}

# Для публикации: токен аутентификации уровня проекта (npm publish требует точного совпадения пути)
//gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/:_authToken=${GITLAB_NPM_TOKEN}

# область действия @company использует реестр уровня группы
# Все пакеты @company/* будут установлены из этого реестра
@company:registry=https://gitlab.com/api/v4/groups/YOUR_GROUP_ID/-/packages/npm/

# Другие публичные пакеты по-прежнему идут в официальную библиотеку
registry=https://registry.npmjs.org/

Настройте publishConfig в package.json для публикации пакета в соответствующем GitLab Project Registry.

{
  "name": "@company/my-package",
  "publishConfig": {
    "@company:registry": "https://gitlab.com/api/v4/projects/YOUR_PROJECT_ID/packages/npm/"
  }
}

Заключение

Благодаря стратегии “Единого реестра группы загрузки” и “Независимого реестра проекта публикации” мы можем значительно снизить затраты на обслуживание и сделать процесс разработки более плавным.

Освоив эту логику, GitLab NPM Registry станет мощным помощником в процессе разработки вашей компании!