JSR: El registro de JavaScript
Un nuevo registro de paquetes de JavaScript llamado JSR, creado por el equipo de Deno, busca ofrecer una alternativa primero para TypeScript y solo ESM a npm, sin dejar de ser interoperable con los paquetes y herramientas npm existentes. Quienes lo apoyan destacan el manejo integrado de tipos, la documentación automática, la procedencia y una integración más estrecha con los runtimes modernos como ventajas clave frente al envejecido registro de npm, controlado por Microsoft. Quienes lo critican cuestionan la necesidad de otro registro central, temen la fragmentación del ecosistema, los problemas de nombres y gobernanza, y expresan preocupación por decisiones de diseño como penalizar la inferencia intensiva de tipos y depender mucho de TypeScript en ausencia de un estándar formal.
Propósito y diseño de JSR
- Nuevo registro centralizado para JavaScript/TypeScript, creado por el equipo de Deno pero pensado para ser agnóstico al runtime.
- Motivado por problemas con las importaciones basadas en URL en Deno: dependencias duplicadas (sin deduplicación basada en semver) y URLs frágiles que pueden desaparecer.
- Se centra en TypeScript y ESM: publicas el código fuente en TS y JSR se encarga de la transpilación, la generación de
.d.ts, la documentación y las compilaciones multiplataforma. - Las importaciones HTTPS en Deno siguen siendo compatibles, pero JSR se presenta como la opción predeterminada más robusta.
TypeScript, enfoque solo en sintaxis y “tipos lentos”
- El registro se basa en la sintaxis de TypeScript, no en el sistema de tipos completo; no hay análisis basado en TSC.
- Para mantener las operaciones de tipos rápidas y estables, fomenta fuertemente tipos explícitos para la API pública y limita la inferencia (“tipos lentos” obtienen una puntuación más baja, pero aun así pueden publicarse).
- Se citan como alivio de la fricción próximas opciones de TS como
isolatedDeclarationsy las correcciones rápidas del editor.
Relación con npm y las herramientas
- JSR es un registro, no un gestor de paquetes; se integra con las herramientas existentes mediante APIs al estilo npm y
node_modules. - Los módulos de JSR pueden depender de módulos npm y viceversa; hay una capa de compatibilidad con npm que emite JS +
.d.tspara Node. - Hay cierta confusión por expresiones de marketing como “superset of npm”; varios comentaristas sugieren términos más claros como “aditivo” o “complementario”.
- Los flujos de trabajo existentes de Deno a npm (por ejemplo,
dnt) siguen siendo viables a corto plazo; a largo plazo, JSR busca cubrir ese caso de uso directamente.
Gobernanza, espacios de nombres e inmutabilidad
- Los ámbitos están curados; los ámbitos obvios de marcas pueden reasignarse a propietarios verificados.
- Las versiones anteriores permanecen inmutables y disponibles; el nuevo propietario del ámbito puede publicar versiones más nuevas bajo el mismo ámbito.
- Algunos ven esto como una repetición de dramas pasados de nombres en registros; otros proponen nombres basados en DNS o URN para evitar colisiones.
Uso en runtime, navegador y WASM
- Funciona con Deno, Node, Bun; Node usa una capa de compatibilidad.
- El uso en navegador aún no es de primera clase; se mencionan servicios externos como esm.sh para importaciones HTTP/ESM de paquetes JSR.
- Se prevé soporte para importaciones de código fuente WASM mediante la propuesta de source-phase imports.
Recepción y críticas
- Entusiasmo: mejor compatibilidad con TS, documentación automática, procedencia, alternativa a un npm controlado por Microsoft, implementación de código abierto.
- Escepticismo: añade otro registro y una fragmentación percibida; algunos creen que las funciones podrían resolverse con mejores herramientas del lado de npm.
- Preocupaciones sobre una excesiva dependencia de TS, “magia” adicional en la compilación, comportamiento de semver y marketing (el nombre “JSR”, el enfoque en TS frente a la marca “JavaScript”, páginas de aterrizaje con estilo de IA).