Конец монополии npm?? Краткий гайд-обзор по Github package registry.

Недавно github выкатил новый продукт — GPR в массы. Изначально это выглядело как долгожданный конец монополии npmjs.org в этой нише, но так ли это?

Доступ к github packages я получил ещё во времена бета-тестирования, однако, долгое время у меня не доходили руки до фактического тестирования сервиса. И вот я всё же собрался с силами и протестировал новоявленный registry. Далее опишу как всем этим пользоваться, а в конце попробую подвести итоги и вынести некоторый вердикт.

 

1. Авторизация в реестре github

 

Когда мы говорим npm login --registry https://npm.pkg.github.com, то npm нас спрашивает: login, password, email.

Казалось бы, всё очевидно и просто, вот только в случае с GPR, нужно вводить не пароль от вашего аккаунта Github, а personal token.

Генерируется он в разделе настроек Settings -> Developer settings -> Personal access tokens. И для публикации пакетов ему требуются права read:packages, write:packages.

Раздел токенов

 

После того как всё вбили и авторизовались, можно начинать пользоваться GPR.

 

2. Публикация пакетов

 

Я создал github репозиторий и сгенерировал стандартный package.json файл:

Для того, чтобы публиковать пакет в реестре GPR, а не NPM, в наш package.json файл нужно добавить настройку publishConfig:

 

{
  // npm настройки
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/<USERNAME>"
  }
}

 

Вместо USERNAME, указываем свой логин/организацию, например я прописал @ikenfin.

После того, как всё это прописано, опубликовать пакет можно знакомой командой npm publish.

Ничего сверхъестественного и если всё сделано правильно, то в разделе packages появится наш npm-пакет:

 

3. Установка пакетов из Github package registry

 

Если мы зайдём на страницу созданного пакета, то увидим предлагаемую github инструкцию по установке:

Попробуем выполнить установку:

Github забыли кое-что упомянуть...

если мы просто "от балды" выполним предлагаемую команду установки, то естественно получим ошибку (если в npmjs нет пакета с таким же названием), поскольку наш npm ищет пакет в стандартном реестре пакетов.

 

Для того чтобы всё у нас заработало, github даёт такую инструкцию:

 

Из документации github pages:

In the same directory as your package.json file, create or edit an .npmrc file to include a line specifying GitHub Packages URL and the account owner. Replace OWNER with the name of the user or organization account that owns the repository containing your project.

registry=https://npm.pkg.github.com/OWNER

 

Хорошо, создаём файл .npmrc, вписываем туда строчку registry=https://npm.pkg.github.com/@ikenfin, запускаем установку пакета, и-и-и:

 

Окей, вот как это работает.

По сути, эта настройка говорит npm использовать наш регистри как основной и единственный (по крайней мере это так в 6.5.0 работает).

 

Github немного лукавит, поскольку такой сетап далеко не всегда корректен. 

Это ОК, если у вашего проекта нет внешних зависимостей, либо все эти зависимости опубликованы в том же registry, то проблем не будет.

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

 

И как же забороть проблему??

Помимо формата registry=URL/AUTHOR, также в .npmrc мы можем использовать "пространства имён":

# было
# registry=https://npm.pkg.github.com/@ikenfin
# стало
@ikenfin:registry=https://npm.pkg.github.com

 

Чтож, попробуем теперь установить наш злополучный пакет:

 

Однако, тут есть один момент. Если мы заглянем в наш package.json файл, то увидим такой список зависимостей:

Я не знаю почему это произошло, могу только догадываться, что это связано как раз с настройкой registry в .npmrc, однако по факту мы получаем кривой package.json.

Конечно, благодаря package-lock.json, другие разработчики подтянут проект без проблем, однако если при каких-то обстоятельствах он будет недоступен, то и пакеты установить без ручного допиливания списка зависимостей не получится.

 

4. Общие впечатления от сервиса

 

В целом, мне понравилась сама идея.

 

Если речь идёт о корпоративном closed-source проекте, то инфраструктура github вполне себе закроет множество потребностей — от приватных репозиториев/пакетов, до автоматизации сборки, тестирования и публикации с помощью actions.

Кроме того, помимо npm-пакетов, там поддерживаются ещё и docker-образы и несколько других пакетных систем, что очень неплохо для разработки закрытых энтерпрайзных и не очень продуктов.

 

Если смотреть со стороны opensource — на этом поприще я не вижу будущего у платформы Github package registry для npm модулей. Думаю, большинство открытых проектов если и будут его использовать, то только в качестве fallback для проектов в npmjs.

 

Так положит ли github packages конец монополии npmjs?

В какой-то мере — да. Вероятно многие компании, использующие github для хранения приватных репозиториев, переведут и хранение своих закрытых пакетов из NPM в GPR. Но, что касается абсолютного большинства открытых проектов — не думаю что мы в какой-то момент начнём устанавливать большинство зависимостей из Github packages registry.

 

Ну, а ты что думаешь %USERNAME%?

Взлетит Github Package Registry или всё же будет нишевым продуктом?