JSR: O Registro JavaScript
Um novo registro de pacotes JavaScript chamado JSR, criado pela equipe do Deno, pretende oferecer uma alternativa ESM-only e focada em TypeScript ao npm, ao mesmo tempo em que continua interoperável com pacotes e ferramentas npm existentes. Os defensores destacam o manuseio de tipos integrado, documentação automática, proveniência e integração mais estreita com runtimes modernos como vantagens principais em relação ao registro npm envelhecido e controlado pela Microsoft. Os críticos questionam a necessidade de mais um registro central, temem fragmentação do ecossistema, problemas de nomenclatura e governança, e expressam preocupação com escolhas de design como penalizar inferência pesada de tipos e depender fortemente do TypeScript na ausência de um padrão formal.
Propósito e Design do JSR
- Novo registro centralizado para JavaScript/TypeScript, construído pela equipe do Deno, mas pensado para ser agnóstico em relação ao runtime.
- Motivado por problemas com imports baseados em URL no Deno: dependências duplicadas (sem deduplicação baseada em semver) e URLs frágeis que podem desaparecer.
- Foca em TypeScript e ESM: você publica código-fonte TS e o JSR cuida da transpilação, geração de .d.ts, documentação e builds entre runtimes.
- Imports HTTPS no Deno continuam suportados, mas o JSR é posicionado como o padrão mais robusto.
TypeScript, Abordagem Apenas de Sintaxe e “Tipos Lentos”
- O registro depende da sintaxe do TypeScript, não do sistema de tipos completo; não há análise baseada em TSC.
- Para manter as operações de tipos rápidas e estáveis, ele incentiva fortemente tipos explícitos na API pública e limita a inferência (“tipos lentos” recebem uma pontuação menor, mas ainda podem publicar).
- Opções futuras do TS, como
isolatedDeclarations, e correções rápidas do editor são citadas como formas de reduzir o atrito.
Relação com npm e Ferramentas
- JSR é um registro, não um gerenciador de pacotes; integra-se com ferramentas existentes por meio de APIs no estilo npm e
node_modules. - Módulos JSR podem depender de módulos npm e vice-versa; há uma camada de compatibilidade com npm que emite JS + .d.ts para Node.
- Há certa confusão com linguagem de marketing como “superset do npm”; vários comentadores sugerem termos mais claros, como “aditivo” ou “complementar”.
- Fluxos de trabalho existentes de Deno para npm (por exemplo, dnt) continuam viáveis no curto prazo; no longo prazo, o JSR pretende cobrir esse caso de uso diretamente.
Governança, Namespaces e Imutabilidade
- Os escopos são curados; escopos óbvios de marcas podem ser reassignedos a proprietários verificados.
- Versões anteriores permanecem imutáveis e disponíveis; o novo proprietário do escopo pode publicar versões mais novas sob o mesmo escopo.
- Alguns veem isso como uma repetição de dramas antigos de nomenclatura de registros; outros propõem nomes baseados em DNS ou URN para evitar colisões.
Runtime, Browser e Uso com WASM
- Funciona com Deno, Node, Bun; o Node usa uma camada de compatibilidade.
- O uso no navegador ainda não é de primeira classe; serviços externos como esm.sh são mencionados para imports HTTP/ESM de pacotes JSR.
- Suporte planejado para imports de código-fonte WASM por meio da proposta de source-phase imports.
Recepção e Críticas
- Entusiasmo: melhor suporte a TS, docs automáticas, proveniência, alternativa a um npm controlado pela Microsoft, implementação open source.
- Ceticismo: adiciona outro registro e uma fragmentação percebida; alguns veem recursos como algo solucionável com ferramentas melhores do lado do npm.
- Preocupações com dependência excessiva de TS, “magia” extra de build, comportamento de semver e marketing (nome “JSR”, foco em TS vs branding “JavaScript”, landing pages parecidas com IA).