npm vs JSR: publicar ESM-first con tipos nativos

Durante años, “publicar un paquete” significó exactamente una cosa: subirlo al registro público de npm. Pero el registro es una capa sustituible, no una ley física. Escribiste npm install mil veces creyendo que hablabas con npm, cuando en realidad hablabas con una interfaz —nombres con scope, enrutado por .npmrc, tarballs por HTTP— que resulta estar implementada por defecto por el registro público. En 2026 JSR ocupa esa misma interfaz con un backend distinto: ESM-first, TypeScript de origen y tipos nativos sin build previo. Conocer el abanico es dejar de estar atado a un solo destino.

El registro como capa sustituible

La abstracción que has usado sin nombrarla se descompone en tres piezas estables, y ninguna presupone quién está detrás:

• Nombres con scope: @scope/nombre es un identificador que no dice qué servidor lo sirve.
• Enrutado por .npmrc: una línea mapea cada scope a la URL de un registro concreto y su token.
• Tarballs por HTTP: el servidor entrega un .tgz con su integridad, y cualquier gestor sabe instalarlo.

Esa interfaz es lo estable; el registro detrás es intercambiable. Una vez que lo ves, el mapa se abre, porque JSR no reinventa la interfaz: la reimplementa con un backend diseñado desde cero para el JavaScript moderno, enrutado por el mismo mecanismo de siempre.

# el scope reservado @jsr se enruta al registro de JSR; el resto, al publico
@jsr:registry=https://npm.jsr.io/

JSR es el registro impulsado por el equipo de Deno, y sus decisiones de diseño son deliberadas y rompedoras:

• Solo ESM: no admite el formato CommonJS heredado, lo que simplifica todo el modelo de módulos.
• TypeScript de origen: sirve el código con tipos nativos y transpila bajo demanda para cada runtime; los tipos nunca se desincronizan de la fuente porque no hay un paso de declaración que mantener.
• Solo con scope: todo paquete es @scope/nombre, sin el espacio plano y disputado del registro clásico.
• Procedencia y puntuación integradas: firma vía OIDC de serie, más una puntuación de calidad que premia documentación, exports correctos y compatibilidad cross-runtime.

Interoperabilidad y slow types

Lo decisivo es que JSR no te encierra: interopera con el ecosistema existente. Añades un paquete de JSR a un proyecto Node con npx jsr add, que escribe en tu package.json una dependencia enrutada al scope reservado @jsr, y el registro sirve un tarball compatible —ya transpilado a JavaScript con sus .d.ts— para que npm, pnpm, yarn o bun lo instalen sin enterarse de que el origen era TypeScript puro. Un paquete no necesita package.json: le basta un jsr.json con su name, su version y sus exports apuntando al .ts.

# anade un paquete de JSR desde distintos gestores
npx jsr add @std/encoding      # npm
pnpm dlx jsr add @std/encoding # pnpm
bunx jsr add @std/encoding     # bun
deno add jsr:@std/encoding     # deno, de forma nativa

# publicar a JSR desde el directorio del paquete
npx jsr publish

{
  "name": "@acme/parser",
  "version": "1.0.0",
  "exports": "./mod.ts"
}

El puente con npm se apoya en tres piezas que operan sin que el consumidor las note:

• el scope reservado @jsr, al que se enruta toda dependencia de JSR en un proyecto npm;
• un tarball transpilado con sus .d.ts, que el registro genera a partir del .ts de origen;
• el mismo protocolo de nombres y HTTP, para que npm, pnpm, yarn o bun instalen sin cambios.

La restricción que más sorprende es la regla de los slow types: JSR exige que la API pública lleve tipos explícitos, sin depender de la inferencia para los símbolos exportados. No es un capricho, sino la condición que le permite generar documentación y transpilar por runtime a gran velocidad sin ejecutar el compilador completo.

// slow type: JSR no puede resolver el retorno publico sin compilar todo
export function crear(config) { return { id: config.id, activo: true } }

// rapido: el tipo explicito hace la superficie legible y transpilable
export function crear(config: Config): Instancia { /* ... */ }

El efecto secundario es virtuoso: la regla te empuja a anotar tu superficie pública, lo que de paso mejora la calidad de tu API y la de los tipos que reciben tus consumidores. Una limitación técnica del registro se convierte, sin pretenderlo, en una presión hacia el buen diseño.

Cross-runtime y cuándo elegir cada uno

El otro eje del diseño es la ejecución en múltiples runtimes. Como JSR sirve la fuente TypeScript y transpila por objetivo, el mismo paquete puede ejecutarse en Node, Deno, Bun, workers al borde y el navegador, y el registro comprueba y puntúa esa compatibilidad. Es el destino natural de una librería pensada para vivir fuera de un solo entorno.

La compatibilidad no es una promesa vaga, sino una comprobación que el registro ejecuta y refleja en la puntuación:

• Node y Bun: reciben el tarball transpilado con sus .d.ts y lo instalan como cualquier dependencia npm.
• Deno: consume el .ts de origen de forma nativa, sin transpilación intermedia.
• Navegador y workers al borde: solo ESM y APIs estándar, justo lo que el diseño de JSR favorece.

flowchart TD
SRC[paquete en TypeScript] --> JSR[registro JSR sirve la fuente]
JSR --> DENO[deno consumo nativo]
JSR --> NODE[node via scope jsr transpilado]
JSR --> BUN[bun]
JSR --> EDGE[workers al borde]
style SRC fill:#89b4fa,color:#11111b
style JSR fill:#cba6f7,color:#11111b
style NODE fill:#a6e3a1,color:#11111b

Ni JSR ni npm ganan en abstracto: cada perfil de paquete tiene un destino natural. La decisión se toma por paquete, no por convicción global.

El criterio, afinado, se ordena por la naturaleza del paquete y de su público:

• Nace en TypeScript y vive cross-runtime: JSR, por los tipos nativos y la compatibilidad verificada sin paso de build.
• Consumidores atados a CommonJS o a herramientas que asumen npm: el registro clásico, donde el peso del ecosistema juega a favor.
• Addons nativos o binarios: npm, porque JSR es solo ESM y solo JavaScript o TypeScript.
• Máximo alcance sin forzar a nadie a cambiar: publicación dual en ambos destinos.

La estrategia madura en 2026 es a menudo esa publicación dual: publicas en JSR para quien quiere tipos nativos, docs y cross-runtime, y en npm para no dejar fuera al enorme ecosistema que asume el registro clásico y sus herramientas. Como ambos hablan la misma interfaz de nombres, enrutado y tarballs, sostener los dos destinos desde un solo repositorio cuesta poco y no obliga a ningún consumidor a cambiar su forma de trabajar.

# publicacion dual desde el mismo repositorio
npx jsr publish   # a JSR: sirve la fuente TypeScript con tipos nativos
npm publish       # a npm: sirve el tarball transpilado clasico