2026: Deno и JSR на удалённом Mac — матрица решений: lockfile, кеш и параметры CI

Пайплайн ломается там, где встречаются два реестра, один корень кеша и всплеск параллельных HTTP-сессий на перегруженном канале. На общем удалённом Mac несколько job с deno install легко совпадают по времени и конкурируют за диск и TLS.

Боль 1 — двойной выход в интернет: jsr: ходит на инфраструктуру JSR, npm: — на npm-реестр (или зеркало). Allow list и NO_PROXY должны закрывать обе цепочки; иначе «рандомные» таймауты выглядят как баг приложения.

Боль 2 — связанный кеш: общий DENO_DIR без политики ротации даёт «фантомы» частичных загрузок между раннерами, особенно после обрыва tarball.

Боль 3 — lock и отставание зеркала: свежий deno.lock в LAN может не пройти --frozen в CI, если корпоративное зеркало npm отстаёт от апстрима. Это сигнал инфраструктуры, а не повод отключать заморозку.

На практике команда обнаруживает проблему не в самом TypeScript, а в том, что два независимых контура загрузки умножают поверхность отказа: сбой на JSR не компенсируется кешем npm и наоборот. Поэтому runbook должен явно перечислять оба контура и точки наблюдаемости (код ответа, задержка до первого байта, доля повторов). Для сравнения с «классическим» стеком Node полезно держать под рукой материал про зеркала Git, npm и Homebrew — те же идеи прокси, allow list и дисковых квот переносятся на Deno с поправкой на DENO_DIR.

Используйте строки таблицы как пункты для allow list, PCAP и дизайн-дока — каждая спецификация импорта это отдельная линия комплаенса.

Если вы фиксируете политику «только JSR для новых публичных пакетов, npm для легаси», заранее опишите исключения и процесс обновления lockfile — иначе разработчики снова смешают источники в одном PR, и CI станет лотереей. На удалённом Mac выгодно иметь отдельный пул под Deno-пайплайны с заранее прогретым кешом (но не общим на запись с другими стеками), чтобы холодный старт не съедал весь бюджет таймаута.

Вынесите блок в пролог shell-шага CI и закрепите пути в runbook рядом с YAML — так SSH-отладка на том же Mac совпадёт с сервисной УЗ.

Краткая последовательность: (1) обновить lock на доверенной машине отдельным PR; (2) зафиксировать тот же DENO_DIR в CI и при ручной отладке; (3) разделить шаг «загрузка» и «тесты», чтобы регистри ошибся раньше длинных сценариев; (4) curl -I к JSR и npm через боевой прокси; (5) при заполнении диска >80 % планово чистить устаревшие поддеревья кеша.

Import map и deno.json: централизованная карта импортов упрощает смену зеркала или внутреннего прокси без массового редактирования исходников. Зафиксируйте в репозитории, какая команда считается канонической для обновления lock (deno install vs точечный deno cache), и закрепите её в CONTRIBUTING — расхождение команд между ноутбуком и CI — частая причина «плавающего» diff в deno.lock.

Версия Deno: pin через deno.json vendor / официальный installer или контейнер; на Apple Silicon убедитесь, что бинарь arm64, а не Rosetta, если вы сравниваете тайминги с Linux-раннером. Для кросс-командной согласованности полезно вывести deno --version в артефакты job и падать при расхождении с ожидаемой строкой.

У Deno нет одного «глобального» лимита параллельных HTTP-загрузок для всего рантайма — упирайтесь в число одновременных воркфлоу на хост и в таймауты оркестратора. deno test --parallel ускоряет CPU-bound тесты, но не отменяет конкуренцию за сеть и диск с соседними job.

Silicon быстрый, аплинк часто узкий: сначала добавляйте раннеры или отдельные узлы, и только потом поднимайте параллелизм на одном хосте.

deno test --parallel хорошо масштабирует CPU-bound наборы, но после холодной загрузки зависимостей диск и страничный кеш ещё «прогреваются» — первый прогон после очистки DENO_DIR закладывайте с большим запасом по времени, последующие можно ужимать. Если оркестратор позволяет, вынесите «install/cache» в отдельный reusable job с собственным кешем артефактов ( tarball DENO_DIR или снимок подпапок), а тесты запускайте на «теплом» дереве; это особенно полезно при десятках транзитивных npm: пакетов.

На уровне организации заведите метрику «время до первого успешного deno install --frozen» по пулу Mac: рост медианы за неделю часто предвещает проблемы с прокси или переполнением диска раньше, чем упадёт доступность реестра по статусу HTTP.