Конец монополии 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. ReplaceOWNER
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 или всё же будет нишевым продуктом?