Источник: Nuances of Programming
Сервис управления пакетами 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.
Примечание: здесь вам потребуется создать ваш собственный репозиторий и добавить о нем информацию в нижеследующий файл.
И, наконец, публикуем пакет с помощью npm publish .
Примечание: также есть возможность создавать пакеты GitHub, применяющие другие пакеты NPM в качестве зависимостей. eDEX-UI — один из современных пакетов, доступных в реестре GitHub. Это кроссплатформенный эмулятор терминала и системный монитор, который выглядит как научно-фантастический компьютерный интерфейс. Но при углубленном изучении реализаций пакета оказывается, что они используют зависимости NPM, такие как electron, electron-rebuild, node-abi, и node-json-minify.
Шаг 3. Применение пакета в качестве зависимости
Вы можете добавить пакет в любой из проектов.
- Создаем локальный файл .npmrc в корневой директории проекта и добавляем строку @OWNER :registry=https://npm.pkg.github.com/ по аналогии с тем, что мы делали при создании пакета.
- Добавляем пакет в проект с помощью Yarn или NPM, например yarn add @ChameeraD/pkg-git-demo .
- Наконец, вы можете импортировать пакет в код и начать с ним работу:
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 не составит труда.
Благодарю за внимание!
Читайте также:
Перевод статьи Chameera Dulanga : GitHub Package Registry: Is it Worth Trying Out?
