В гостях у GitHub Package Registry

Сервис управления пакетами GitHub Package Registry был разработан и представлен в середине 2019 компанией Microsoft. Его создание, наряду с приобретениями GitHub и NPM, говорит о стремлении Microsoft расширить экосистему GitHub. Да и сам GitHub акцентирует внимание на этом факте таким вот рекламным слоганом:

“Пусть ваши пакеты с кодом чувствуют себя как дома”  —  GitHub.

Но достаточного ли одного этого аргумента, чтобы начать пользоваться этим сервисом? Да и вообще, есть ли необходимость еще в одном менеджере пакетов? 

Ответ на эти вопросы не прост, особенно в связи с наличием таких популярных реестров JavaScript, как Bit.

Компоненты Bit —  это “супер набор” пакетов Node. С ними можно работать как со стандартными пакетами, при этом они также содержат исходный код, историю изменений и другие конфигурации, позволяющие обслуживать их как независимые проекты. Поэтому если дело касается добавления пакета в репозиторий, то варианты отнюдь не ограничиваются Github Packages. 

Для принятия решения нам явно нужно больше информации. 

Стоит ли попробовать?

Если вы один из 40 миллионов пользователей GitHub, то доступ к данному сервису можно получить через выделенную для него вкладку, расположенную на странице вашего профиля или организации.

Начало работы с GitHub Package Registry оказалось простым и понятным. Я выбрал бесплатный план Free plan, и его оказалось достаточно для создания проекта с несколькими частными пакетами. 

Однако уместен вопрос, будет ли менеджер пакетов GitHub позиционироваться как главный программный продукт? И к настоящему моменту он действительно стал одним из таковых в GitHub. Кроме того, GitHub Package Registry уже оснащен набором высокоэффективных возможностей, которые выводят его на новый уровень. 

Рассмотрим некоторые из них. 

1. Поддерживает 5 языков и клиентов 

В отличие от NPM, ориентированного на пакеты NodeJS, GitHub Package Registry поддерживает спектр типов и клиентов, как показано ниже. 

А в грядущих обновлениях ожидается пополнение поддерживаемых инструментов и клиентов. Например, на очереди поддержка Swift, находящаяся на стадии бета-тестирования. 

Благодаря этой возможности GitHub Package Registry позволяет размещать разные пакеты ПО в одном месте. Он прекрасно работает и с микросервисами, технология которых может отличаться от проекта к проекту. 

2. Интеграция рабочего процесса и GitHub Actions 

Комбинация GitHub APIs, GitHub Actions и WebHooks способствует созданию полностью интегрированного сквозного рабочего процесса DevOps, включающего конвейеры CI/CD. С помощью GraphQL и WebHooks также можно настроить рабочие потоки, предшествующие публикации и сопровождающие ее.

GitHub Actions уже содержит перечень предварительно сформулированных задач для упрощения работы с пакетами GitHub. 

В общем с помощью нативной интеграции с GitHub Actions вы можете автоматизировать весь жизненный цикл пакета и операций с ним в одном месте. 

3. Контроль доступа 

GitHub Package Registry позволяет в одном месте управлять разрешениями на использование репозиториев кода и пакетов, а также упрощает контроль доступа к конвейерам CI/CD. Более того, аутентификация GitHub может служить для доступа, как к исходному коду, так и к частным пакетам.

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

В зависимости от требований ваш пакет может быть как общедоступным, так и частным. 

4. Информация о коде и пакете доступна в одном месте 

Подобно другим аналогам GitHub Package Registry позволяет перед скачиванием просматривать содержимое пакетов, загружать статистику и изучать историю изменений. 

Поскольку по звездам и форкам репозиториев GitHub можно судить об их активности, то именно там и стоит искать актуальные пакеты для своего кода. 

Даже работая с пакетами NPM, я обычно заходил на GitHub, чтобы посмотреть количество звезд, число участников, дату последнего коммита, а теперь все это доступно в одном месте.  

С чего начать, если я уже размещаю пакеты в другом менеджере? 

А делать-то особо ничего и не придется, особенно в случае общедоступных пакетов. Предположим, что ваши частные пакеты зависят от другого открытого реестра, например NPM. При перемещении исходных пакетов в GitHub Package Registry эти зависимости продолжат свою бесперебойную работу. Фактически потребуется лишь изменить адрес URL и механизм контроля доступа. 

Давайте на небольшом примере рассмотрим поэтапный процесс публикации пакета NPM в GitHub Package Registry.

Шаг 1. Аутентификация в GitHub Package Registry 

Прежде всего, необходимо получить токен доступа GitHub для аутентификации личности в реестре. Его можно создать здесь https://github.com/settings/tokens/new или воспользоваться уже имеющимся. В нашем примере он значится как githubReg.

Далее нужно настроить файл конфигурации .npmrc, который определяет взаимодействие клиента NPM с самим реестром NPM. Запускаем терминал и выполняем code .npmr, что приведет к открытию пустого файла и замене следующей строки на ваш access_token.

//npm.pkg.github.com/:_authToken=TOKEN

Теперь инициализируем новый проект NPM и откроем его в VSCode с помощью npm init. 

Шаг 2. Публикация пакета 

Создаем локальный файл .nmprc в корневой директории проекта и добавляем следующую строку. В нижеуказанном примере заменяем OWNER на имя пользователя или организации. 

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

Создаем основной файл JavaScript и пишем небольшую функцию. В нашем случае я создал файл index.js в корневой директории для тестирования пакета. 

module.export = () => {

   console.log("hello new one");

}

Затем проверяем имя пакета и добавляем репозиторий в package.json проекта, после чего отправляем все изменения в Git.

Примечание: здесь вам потребуется создать ваш собственный репозиторий и добавить о нем информацию в нижеследующий файл.

{

   "name": "@ChameeraD/pkg-git-demo",

   "version": "1.0.0",

   "description": "",

   "main": "index.js",

   "scripts": {

      "test": "echo \"Error: no test specified\" && exit 1"

   },

   "repository": {

      "url": "git://github.com/ChameeraD/pkg-git-demo.git."

   },

   "publishConfig": {

      "registry":"https://npm.pkg.github.com/"

   },   

   "author": "",

   "license": "ISC"

}

И, наконец, публикуем пакет с помощью npm publish.

Примечание: также есть возможность создавать пакеты GitHub, применяющие другие пакеты NPM в качестве зависимостей. eDEX-UI  —  один из современных пакетов, доступных в реестре GitHub. Это кроссплатформенный эмулятор терминала и системный монитор, который выглядит как научно-фантастический компьютерный интерфейс. Но при углубленном изучении реализаций пакета оказывается, что они используют зависимости NPM, такие как electron, electron-rebuild, node-abi, и node-json-minify.

Шаг 3. Применение пакета в качестве зависимости 

Вы можете добавить пакет в любой из проектов. 

1. Создаем локальный файл .npmrc в корневой директории проекта и добавляем строку @OWNER:registry=https://npm.pkg.github.com/ по аналогии с тем, что мы делали при создании пакета. 
2. Добавляем пакет в проект с помощью Yarn или NPM, например yarn add @ChameeraD/pkg-git-demo . 
3. Наконец, вы можете импортировать пакет в код и начать с ним работу:
   import demoPkg from ‘@ChameeraD/pkg-git-demo’;
 demoPkg();

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

Ограничения менеджера пакетов GitHub 

Для краткости обозначим только те из них, которые касаются большинства разработчиков. 

Поддержка только объединенных пакетов NPM 

Перенос необъединенных в общую область пакетов из NPM в GitHub Package Registry может стать трудоемким процессом, поскольку GitHub поддерживает только их объединенные варианты, например npm install @source/my-package.

Чтобы сработало перемещение существующих пакетов без областей вам придется добавлять области и изменять импорты кода. 

Сложности при перемещении пакетов 

Процесс перемещения из нескольких реестров затрудняется различиями применяемых в них технологиях (Docker, .NET).

Если вы уже задействуете какой-либо реестр, то в процессе переноса из-за неучтенных обновлений может возникнуть конфликт версий. Например, поддерживая пакет и в NPM, и в реестре GitHub, необходимо также поддерживать и его версию. Поэтому при планировании переноса нужно учитывать зависимости и стремиться использовать единый реестр пакетов.

Менее настраиваемый 

Да, именно так. Пользователи не могут применять настраиваемые механизмы аутентификации и иметь реестры с собственным сервером. Отсутствие этих возможностей ограничивает разработчиков, работающих в режиме “оффлайн” и условиях слабого интернет соединения. 

Заключение

Публикуя пакет в GitHub Package Registry, вы получаете новый опыт и возможность хранить исходный код и пакеты в одном месте. 

С учетом уже имеющейся тенденции поддержки многих типов пакетов, нескольких уж точно, дальнейшее развитие GitHub Package Registry, вероятно, приведет к охвату всех из них. Кроме того, если вы уже задействуете GitHub для исходных репозиториев, то освоить GitHub Package Registry не составит труда. 

Благодарю за внимание!