JSR: реестр пакетов, где публикуют TypeScript, а не сборку

Зачем ещё один реестр

npm появился в 2010 году, когда TypeScript ещё не существовало, а модули были только CommonJS. С тех пор публикация библиотеки превратилась в ритуал: собрать в ESM и CJS, сгенерировать .d.ts, собрать карту исходников, проверить exports в package.json, не забыть про types. Половина проблем с «не резолвятся типы» на GitHub растёт отсюда.

JSR, JavaScript Registry, задуман как реестр, в котором ничего этого делать не нужно. Публикуется сам TypeScript, а всё остальное делает сервер.

Как это работает

Пакет описывается коротким файлом jsr.json с именем, версией и точками входа:

{
  "name": "@acme/slug",
  "version": "1.2.0",
  "exports": "./mod.ts"
}

Команда npx jsr publish отправляет исходники. Реестр сам проверяет, что все типы выводимы без «медленных» конструкций, собирает документацию из JSDoc и генерирует .d.ts. Если пакет не прошёл проверку, публикация не состоится, и это лучше, чем узнать о проблеме из issue через месяц.

Пакеты называются с областью видимости, как @scope/name, и только так. Коротких глобальных имён нет, поэтому не бывает споров за request или colors.

Совместимость с npm

Самая важная часть: JSR не требует бросать npm. Для Node и Bun есть слой совместимости, который превращает пакет JSR в обычную зависимость в node_modules:

npx jsr add @acme/slug

В package.json появляется запись с префиксом npm:@jsr/acme__slug, и дальше всё работает как раньше. Пакет JSR может зависеть от пакетов npm, обратное пока невозможно.

Оценка пакета

У каждого пакета есть балл качества: наличие описания, README, документации у экспортов, провенанса публикации из CI и поддержки всех трёх рантаймов. Это не оценка кода, а чек-лист гигиены, но он заметно дисциплинирует авторов.

Провенанс здесь означает, что публикация из GitHub Actions подписывается через OIDC и в реестре видно, из какого коммита собран пакет. Токенов, которые утекают вместе с ноутбуком, не нужно.

Чего не хватает

Экосистема заметно меньше npm. Крупные библиотеки публикуются в JSR, но большинство по-прежнему живёт только в npm. Приватных пакетов и собственных зеркал пока нет, поэтому для внутренних библиотек компании JSR не подходит.

Кому стоит попробовать

Авторам библиотек на TypeScript, уставшим от конфигурации сборки. Тем, кто пишет под несколько рантаймов и не хочет тестировать exports вручную. Для потребителей пакетов разница почти незаметна, и это, пожалуй, лучшая похвала.