Deno 2.8

• deno add e deno install agora tratam nomes de pacote sem prefixo no CLI como pacotes npm: por padrão, facilitando o uso no lugar de npm install, yarn ou pnpm install em projetos Node existentes
• deno audit fix atualiza automaticamente pacotes npm vulneráveis nas dependências para a versão de patch mais próxima que satisfaça as restrições de versão, e mostra separadamente os itens que exigem mudança de versão major
• Novos subcomandos deno ci, deno pack, deno transpile, deno why e deno bump-version foram adicionados para oferecer suporte a instalações reproduzíveis, geração de tarballs para publicação no npm, conversão de TS→JS, rastreamento do caminho de dependências e atualização de versões em workspaces
• A compatibilidade com a API do Node.js subiu de cerca de 42% no Deno 2.7 para 76,4% (3.405/4.457) no Deno 2.8 com base na própria suíte de testes do Node, e muitos módulos node: agora são carregados sob demanda, acelerando a inicialização de programas que não usam esses módulos
• Em desempenho, a instalação fria de npm ficou 3,66 vezes mais rápida em relação ao Deno 2.7.1, caindo de 3.319ms para 906ms; node:buffer base64 melhorou 3,07 vezes, a taxa de processamento de node:http 2,21 vezes e node:crypto scrypt 2,12 vezes
• Como mudança de compatibilidade, setTimeout e setInterval globais agora retornam o objeto Timeout do Node em vez de um número, então códigos que armazenavam o retorno como number ou o usavam em checagem de tipo ou operações aritméticas devem ser ajustados para NodeJS.Timeout ou equivalente
• TypeScript 6.0.3 vem embutido, e deno check e a LSP passam a incluir lib.node por padrão, interpretando tipos do Node como NodeJS.*, Buffer e process sem configuração adicional
• Em depuração, a aba Network do Chrome DevTools passa a exibir tráfego de fetch(), node:http/node:https e WebSocket do Deno, e --cpu-prof, --cpu-prof-flamegraph e --cpu-prof-md podem gerar perfis do V8, flamegraphs em SVG e relatórios em Markdown
• Em gerenciamento de pacotes e workspaces, foram adicionados o protocolo catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age no .npmrc e --package-json, reforçando a padronização de versões em monorepos, instalações multiplataforma, instalações de produção e a migração de projetos Node existentes
• O deno compile detecta projetos Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start e Vite SSR, executa deno task build e gera o ponto de entrada apropriado, além de mostrar o progresso durante o processamento de grandes árvores de dependências npm
• Em testes e Web API, os valores padrão de sanitizeOps e sanitizeResources em Deno.test() mudaram para false, foram adicionados timeout por teste e cobertura por função, e chegaram OffscreenCanvas, Headers, Request, Response e Streams transferíveis, digest SHA3 e suporte a Web Crypto P-521
• Em upgrade e base do runtime, deno upgrade passa a usar atualizações delta quando possível, reduzindo o download de cerca de 48MB para 3–6MB, deno upgrade pr <number> permite instalar builds de PR, e o V8 foi atualizado da 14.6 para a 14.9

[GN⁺]

Comentários do Hacker News

• Deno é útil por ter um modelo de permissões padrão, ser escrito em Rust e oferecer suporte nativo a TypeScript
  Não sou tão profundo no ecossistema de desenvolvimento web/Node/Bun, mas usei Deno com satisfação em pequenos serviços por alguns anos. Fico curioso por que o Bun parece estar crescendo tão rápido. Não sei se ele é usado mais como bundler e menos como runtime JavaScript
  Só o sistema de permissões já torna o Deno atraente, então não entendo muito bem por que, ao sair do Node para o Bun, as pessoas não vão para o Deno

  • Deno e Bun tinham focos bem diferentes no lançamento. O Deno foi a tentativa do Ryan, criador original do Node, de corrigir muita coisa que ele via como errada no Node, enquanto o Bun desde o início se concentrou em compatibilidade com Node e em rodar frameworks populares como Next.js
    Por muito tempo, muitas dependências e frameworks não funcionavam direito no Deno, e no começo ele nem sequer tinha suporte para instalar dependências via npm. Ao olhar para os ataques à cadeia de suprimentos do npm, talvez o Ryan estivesse certo
    Por isso, o Bun parecia um Node melhor, com mais conveniências e funcionando de imediato com muito menos configuração. A equipe do Deno parece ter percebido que, para ter sucesso, precisava de compatibilidade com Node e vem focando nisso nos últimos anos. Hoje eu diria que o Deno é mais compatível com Node do que o Bun
  • Quando vou começar um projeto paralelo pequeno em TypeScript, em vez de me afogar no mar de npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime, posso simplesmente usar só o Bun
    Só para constar, alguns desses nomes acima são golpes de Pokémon, e os outros são ferramentas reais do ecossistema JS/TS
  • Uso os dois e gosto dos dois. O Bun é mais próximo de um substituto drop-in do Node
    Quando não quero mexer em configuração de testes, tsconfig, módulos ES e coisas assim, ele simplesmente tende a funcionar. O Deno tem uma biblioteca padrão boa e excelente suporte de CLI, e eu também gostava do deno deploy, mas ultimamente ele ficou bem mais trabalhoso
  • Sou principalmente desenvolvedor backend, mas quando mexo um pouco com frontend em projetos pessoais, o Deno parece a escolha mais sensata
    É realmente ótimo de usar, e é uma pena que não tenha se espalhado mais entre o pessoal de JS
  • Usei Deno por cerca de um ano e gostei dele pelos pontos fortes já mencionados, mas havia problemas demais de compatibilidade com pacotes como Astro, Prisma e Vite
    Então migrei para o Bun, e tudo ficou muito mais suave

• Fico curioso sobre o estado atual do Deno
  Node é a solução estável e vai continuar existindo. Agora ele também pode usar TypeScript e em breve talvez permita gerar apps como um único executável, inclusive com dependências nativas
  Bun é confuso, mas rápido, e essa abordagem de incluir tudo na biblioteca padrão é interessante. Além disso, foi adquirido pela Anthropic
  O Deno tinha uma proposta legal com sandbox e facilidade de importar dependências de terceiros, mas sandbox agora parece algo bem mais comum, e o modelo de import no fim talvez nem tenha sido tão melhor assim do que npm add

  • O Deno demitiu cerca de metade da empresa há uns 2 meses: https://news.ycombinator.com/item?id=47467746
  • Quem vê como algo positivo ter sido adquirido pela Anthropic?
  • É bom ter várias opções para o ecossistema não ficar estagnado
  • A distribuição em executável único já é possível. A CLI do meu produto é uma aplicação Node em arquivo único
  • Eu não sabia que seria possível gerar executáveis únicos incluindo dependências nativas. Isso é um recurso poderoso

• Deno é excelente. Estou escrevendo serviços web pequenos e médios em Deno
  Funciona como um relógio suíço, e a filosofia do projeto combina bem com o espírito Unix
  Pessoalmente, acho que as pessoas que fazem o Deno são um pouco humildes demais. Mesmo quando usuários gratos se oferecem para doar ao projeto, eles recusam educadamente. Entendo o motivo, mas isso também pode criar uma pressão financeira desnecessária para o projeto no longo prazo
  Uma assinatura mensal do tipo “por favor, aceitem dinheiro” para usuários que dependem do sucesso de longo prazo do projeto poderia funcionar muito bem

  • Dá realmente muito prazer em usar. Parece quase uma mistura de JavaScript com Go
    É rápido e flexível, oferece um gerenciamento de pacotes um pouco mais sensato e com recursos mais fortes do que outras alternativas JS/TS, um modelo de segurança melhor, uma biblioteca padrão melhor. E também é muito rápido

• Para quem não conhece o nome Deno, ele é um runtime de JavaScript e TypeScript
  Há uma análise comparando o Deno 2.6 com os concorrentes Bun 1.3 e Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Surpreende que o Bun seja tão mais rápido assim no processamento de requisições web. O texto aponta o Zig como fator, mas fico me perguntando se o controle fino de memória por si só explicaria um ganho de mais de 2x sobre o Node
    Do mesmo modo, embora não diga explicitamente, o Bun parece ter sido executado com o cache de pacotes já aquecido. Fico curioso se os outros runtimes também estavam com cache

• O ritmo constante de lançamentos do Deno é impressionante. Estou curioso para ver quais melhorias de desempenho entraram nesta versão

• O novo comando deno pack é uma boa adição para empacotamento seguro e simples
  Se você usa Node.js, algo parecido em comando único pode ser feito com https://www.npmjs.com/package/ts-node-pack
  Agora que o Node.js oferece suporte à importação de módulos .ts, mais repositórios poderão usar isso sem etapa de build nem sem colocar artefatos de build no checkout

  • Ao ler este post do blog, isso foi a primeira coisa em que pensei. O deno pack pode substituir o fluxo atual de npm publish do meu pacote open source e ser bom para continuar movendo o trabalho para algo Deno-first / centrado em Deno
    Por outro lado, como o suporte a TypeScript no Node está crescendo, transformar isso em um pacote npm só de TypeScript também pode ser um recado bem pequeno para o ecossistema
    Ainda assim, fico feliz que o JSR exista como um ecossistema relativamente mais limpo
  • Parece bem parecido com o antigo DNT(https://github.com/denoland/dnt)
    Mas, ao entrar no Deno CLI, a visibilidade aumenta bastante

• Se o Deno tivesse mantido um pouco mais sua proposta inicial por mais tempo, a pressão por compatibilidade com Node teria sido parcialmente preenchida por agentes de IA
  Boa parte dessa pressão vem de uma questão de familiaridade. Se você só sabe configurar coisas com express.js, acaba sentindo que qualquer ferramenta ou runtime posterior precisa oferecer abstrações semelhantes para que a transição pareça “suave”. Isso vale independentemente de quão ruim era a primeira solução
  Hoje em dia, é possível apresentar novas tecnologias ao desenvolvedor entregando junto o pacote técnico necessário com o produto, e isso às vezes realmente substitui a documentação, além de ser bastante eficaz para mostrar abordagens alternativas melhores

  • Se um SDK JS/TS de uma empresa SaaS não funcionar no Deno sem modificações, eu não gastaria nem 1 segundo tentando consertar isso

• Tendo usado Deno em vários projetos de hobby, estou convencido de que o Deno é a direção para a qual o ecossistema JS deveria caminhar
  Ainda assim, recomendá-lo no trabalho fora de casos de uso específicos e geralmente bem limitados é complicado. Em algum momento, se o projeto mudar de rumo por motivos de negócio, no fim você acaba precisando do Node

• Desde o lançamento do Edge.js [1], é bom ver o Deno tratando a compatibilidade com Node.js com mais seriedade
  Em cerca de 2 meses, subiu de algo na casa dos 40% para uns 75%, então, por coincidência ou não, isso é claramente um passo na direção certa
  Parabéns a toda a equipe do Deno
  [1] https://edgejs.org/

  • Vocês não cansam de fazer autopromoção?

• Eu envolvo a maior parte dos idiomatismos do Node e uso Deno como runtime. Funciona bem
  Se o projeto for TypeScript puro, simplesmente rodo com Deno. As opções extras de segurança também são boas, e gosto do fato de scripts de instalação virem desativados por padrão
  Se você ainda usa Node diretamente, eu recomendaria parar. No mínimo, acho melhor usar Bun
  Para trabalho orientado por agentes, quase não há motivo para usar algo além de Rust e TypeScript. Dá para discordar, mas segurança de tipos, segurança de memória e um enorme corpus de trabalho importam. Agentes exploram melhor quando há erros exigentes e padrões embutidos. Para UI, o TypeScript faz mais sentido porque há exemplos de design demais por aí