Давно прошли те времена, когда веб-сайты создавались с нуля (кто-нибудь помнит CGI-BIN?). Не секрет, что современный динамичный интерактивный Интернет построен на модульной технологии, веб-сайты часто используют сотни, если не тысячи Javascript. пакеты. Что происходит, когда кто-то или что-то ломается?
Полное раскрытие информации: я являюсь одним из основателей продукта Bytesafe (https://bytesafe.dev/), который предлагает бесплатные, безопасные и высокодоступные частные реестры npm.
Сегодня большинство разработчиков затрагивают лишь часть кода, необходимого для работы создаваемых веб-сайтов. Это, конечно, замечательная вещь: иметь возможность использовать и повторно использовать код, который кто-то написал и (надеюсь) до сих пор поддерживает. И это также ключ к достижению быстрых результатов с высоким качеством.
На крупных сайтах нередко бывает более 1000 (!) Зависимостей. Например, для тех, кто хочет начать изучение фреймворка дизайна Facebook React, существует официальное Начальное приложение React для получения (https://create-react-app.dev/), которое настраивает современное веб-приложение с использованием React и другие зависимости. В зависимости от версии приложение React имеет более 1500 зависимостей от различных пакетов javascript, предоставленных несколькими сотнями участников.
Представьте, что у одного из этих разработчиков плохой день или того хуже: он теряет учетные данные и взламывает свою учетную запись Github. Как такое событие отразится на повседневной жизни разработчиков и компаний по всему миру? На ум приходит одно (но) известное событие: когда разработчик Азер Кочулу удалил один из своих пакетов из npm. из-за чего в начале марта 2016 года по всему миру вышло из строя множество сборок.
Один из способов защитить себя - использовать прокси-сервер npm, который находится между вами (или вашей командой разработчиков) и большой, постоянно изменяющейся сетью зависимостей, используемой вашим приложением / приложением.
Это была одна из проблем, которую мы намеревались решить с помощью Bytesafe (https://bytesafe.dev/), который в самой простой форме может использоваться в качестве прокси-сервера npm.
Используя такой прокси-сервер NPM, вы можете получать уведомления, когда что-то происходит с вашими зависимостями в Интернете, вместо того, чтобы получать не очень своевременное предупреждение об ошибке от вашего конвейера CI / CD. И вы просто сможете выпустить следующий выпуск, когда конкуренты не смогут.
Так как же использовать частный реестр npm? Это просто, используя уже знакомые вам инструменты. Мы стремимся быть совместимыми с широко используемыми инструментами, такими как npm, yarn и т. Д., Поэтому для начала не должно быть высокого порога.
Сначала создайте бесплатную учетную запись на https://bytesafe.dev (нажмите на подписку), выберите уникальное имя для своей учетной записи, войдите в систему и вуаля! Готово!
После настройки учетной записи создается начальный («по умолчанию») реестр. Создание дополнительных реестров может быть выполнено двумя способами: через Интернет или через интерфейс командной строки bytesafe, если вы предпочитаете свой терминал.
Используя свой реестр Bytesafe по умолчанию, вы можете подключаться к внешнему миру, мы установили по умолчанию upstream,, который позволяет вам извлекать пакеты из npmjs из того же реестра, что и ваши частные пакеты. Для получения дополнительной информации о восходящих потоках, см. Эту статью. Это упрощает рабочий процесс, избавляя от необходимости использовать несколько реестров.
Первое, что вам нужно сделать на стороне клиента, - это сообщить вашей среде о вашем новом реестре:
npm config set registry 'https://example.bytesafe.dev/r/default' npm login
Укажите свои учетные данные, которые видны на странице реестра в bytesafe.dev.
Вытащить пакет из реестра так же просто, как:
npm install 'some-package'
Если указанный реестр Bytesafe не содержит конкретный пакет, пакет будет извлечен из восходящего потока (если настроен) и сохранен в реестре.
Публикация в личном реестре также проста:
npm publish ‘some-package’
0.11.1 ? 0.11.2?
Еще одна проблема, с которой мы, как разработчики, время от времени сталкивались, заключалась в том, чтобы все в команде (и командах, с которыми мы взаимодействовали) использовали пакеты и версии.
Среды разработчика / CD / QA, которые не всегда были синхронизированы, были обычным источником ошибок, путаницы и причиной потери времени.
Вы когда-нибудь пытались помочь коллеге понять, почему ничего не компилируется, в то время как тот же код отлично работает ™ в вашем локальном окружении? Просто чтобы позже слишком много понять, что он или она использует другую версию какой-то зависимости, которую вы давно забыли, зачем она вам вообще нужна? Что ж, у меня есть.
Конечно, есть много способов решить эту проблему. В Bytesafe мы используем две функции (мы называем их политиками): неизменяемые версии и замораживание, которые, по нашему мнению, помогут избежать таких ситуаций (подробнее здесь)
Хорошие и надежные рабочие процессы - нетривиальная задача, и я вернусь к тому, как вы можете использовать Bytesafe в своей, в одной из следующих статей.
Защитите свою цепочку поставок кода и держите эти зависимости под контролем, и удачного кодирования!
❗️ Обновлено 27 апреля 2020 г.: Продолжите эту статью, чтобы получить простой пошаговый пример создания конвейера для развертывания Javascript в вашем собственном частном реестре.
