Lançamento do Deno 2.4

• O deno bundle foi reintroduzido com base em esbuild, permitindo gerar bundles de arquivo único para servidor e navegador, com tree shaking e otimização automáticos
• O suporte a importação de texto/bytes e a estabilização do OpenTelemetry embutido reforçam a observabilidade e a experiência de uso de arquivos externos
• A nova flag --preload, melhorias de conveniência em dependências com deno update, medição de cobertura de scripts, gerenciamento de permissões e compatibilidade com APIs do Node.js foram amplamente aprimorados
• Também foram entregues melhorias em LSP, Jupyter, bench/coverage e suporte a tsconfig, além de várias melhorias de usabilidade

---

Resumo das principais mudanças e novos recursos do Deno 2.4

Retorno do deno bundle

• No Deno 2.4, o subcomando deno bundle, responsável por gerar bundles JavaScript de arquivo único, foi reincorporado com o motor esbuild
• Ele oferece suporte tanto para servidor quanto para navegador e também consegue empacotar dependências de npm e JSR sem problemas
• Com suporte a tree shaking automático e minificação de código (minify), o gerenciamento fica mais prático
• No futuro, estão previstas capacidades de expansão e customização programática do processo de bundling por meio de API de runtime e plugins

Suporte a importação de texto e bytes

• Para permitir embutir arquivos de dados externos, como texto, binários e imagens, no grafo de módulos JavaScript, foi adicionada a flag --unstable-raw-imports
• Antes, era necessário ler arquivos externos com entrada/saída de arquivos (I/O), mas agora é possível usar dados de bytes/texto diretamente na sintaxe de importação ao especificar o tipo do arquivo
• Esse recurso também funciona durante bundling e compilação, facilitando a implementação de embutimento de assets no resultado final
• Junto com o suporte já existente para imports de JSON, Wasm e outros, torna possível gerenciar vários formatos de arquivo de maneira alinhada à especificação
• A especificação ainda está em discussão, mas o Deno busca equilibrar evolução de recursos e tendências de padronização

Estabilização do OpenTelemetry embutido

• O suporte embutido ao OpenTelemetry, introduzido na versão 2.2, foi totalmente estabilizado no 2.4
• Basta definir a variável de ambiente OTEL_DENO=1 para automatizar a coleta de logs, métricas e traces sem precisar de flags adicionais
• Há compatibilidade sem configuração com Node.js e suporte também ao ambiente de deploy do Deno Deploy
• Também é possível fazer correlação/observação automáticas de logs de console.log e requisições HTTP
• Devido às características de uso de recursos, é necessário controlar isso via variável de ambiente

Flag --preload para configuração do ambiente antes da execução

• Foi adicionada a flag --preload, que permite executar previamente código para alterações no ambiente global, carregamento de dados, registro de módulos dependentes e mais antes da execução do script principal
• É útil em diversos cenários de montagem de plataforma, como customização da plataforma ou redefinição de objetos globais
• Pode ser usada nos principais comandos, como deno run, deno test e deno bench

Simplificação do gerenciamento de dependências: deno update

• Foi introduzido o subcomando deno update para atualização automática para as versões mais recentes de dependências npm e JSR
• Permite atualizar várias dependências de uma vez e oferece atualizações precisas com base em compatibilidade Semver
• Também é fornecido como alias do antigo deno outdated --update, melhorando a usabilidade

Cobertura de scripts: deno run --coverage

• Agora é possível coletar cobertura não apenas de cada teste, mas de toda a execução, incluindo subprocessos
• Há gerenciamento flexível dos dados por vários meios, como a variável de ambiente DENO_COVERAGE_DIR
• O relatório HTML de cobertura agora também tem suporte a modo escuro

Variável de ambiente de compatibilidade do Deno DENO_COMPAT=1

• Foi introduzida a variável DENO_COMPAT=1 para melhorar a conveniência e a compatibilidade com o ecossistema npm e projetos baseados em package.json
• Ela aplica automaticamente várias flags instáveis (Unstable), e no futuro o suporte deve ser ampliado, como a omissão de prefixo npm

Melhorias em gerenciamento de permissões e segurança

• A flag --allow-net agora oferece suporte a wildcards de subdomínio e intervalos CIDR
• Foram adicionadas as flags --allow-import, para limitar hosts que podem ser importados pelo código, e --deny-import, para bloqueio explícito
• A API Deno.permissions agora oferece suporte oficial a consultas do tipo "import"
• Ao usar Deno.execPath(), não é mais necessária permissão de leitura, o que facilita o uso do caminho do executável

exports condicionais em package.json

• Foi adicionado suporte a exports condicionais em pacotes npm, reforçando especialmente o suporte a vários ecossistemas, como configurações de servidor React
• Com flags de condição definidas pelo usuário, é possível implementar comportamentos de importação personalizados com flexibilidade

Suporte a bare specifier no deno run

• Agora é possível executar o ponto de entrada do comando usando aliases (bare specifiers) definidos em "imports" no deno.json
• Isso traz grande conveniência em termos de produtividade no desenvolvimento e automação do gerenciamento de módulos

Melhorias de formatação de código para formatos como XML e SVG

• O deno fmt agora oferece formatação automática para vários arquivos de template, como .xml, .svg e .mustache

Reforço no suporte a tsconfig.json

• A precisão no reconhecimento de várias opções, como references, extends, files, include e exclude, foi melhorada
• Isso proporciona compatibilidade aprimorada com frameworks frontend modernos como Vue, Svelte, Solid e Qwik

Maior compatibilidade com variáveis globais e APIs do Node

• Objetos globais do Node.js, como Buffer, global, setImmediate e clearImmediate, agora passam a existir sempre também no código do usuário
• Globais que antes eram exclusivos de pacotes npm agora podem ser usados diretamente, sem flags de comando
• Foi alcançada compatibilidade superior a 95% com node:buffer, node:events, node:querystring, node:quic, node:wasm e outros, com expansão contínua planejada
• A versão base dos tipos @types/node também foi atualizada para 22.15.14

Mudanças no gerenciamento de pacotes npm locais

• O nome da opção de ligação de pacotes npm locais foi alterado de patch para links, alinhando-se ao significado de npm link
• Ao usar a opção antiga, é exibido um aviso de descontinuação, permitindo um gerenciamento de pacotes mais claro

Melhorias em LSP e produtividade de desenvolvimento

• Junto com melhorias de desempenho e funcionalidades do LSP, foram entregues várias conveniências, como suporte do fetch a sockets Unix/Vsock, callback onListen do servidor, gerenciamento de kernels do Jupyter, leitura de comentários em plugins de lint e compatibilidade Markdown nas tabelas de bench/coverage
• Também houve melhorias como reconhecimento do sinal Ctrl+Close no Windows (windows SIGHUP) e formatação Markdown da saída em texto de bench/coverage

Agradecimentos à comunidade e aos contribuidores

• A evolução do Deno 2.4 contou com grande participação e feedback de diversos contribuidores da comunidade
• Para mais detalhes e a lista completa de mudanças, consulte a página de release no GitHub

Conclusão

• O Deno 2.4 traz grandes avanços em várias frentes, como bundling, importação de arquivos externos, observabilidade, permissões/segurança, compatibilidade e produtividade
• Isso permite uma experiência de desenvolvimento integrada simples e poderosa em fluxos modernos de desenvolvimento e projetos do ecossistema frontend e Node
• Informações adicionais, notícias mais recentes e o histórico completo de mudanças podem ser consultados na documentação oficial, no blog e na página de release do GitHub

[GN⁺]

Comentários do Hacker News

• Gosto muito do conceito do Deno, então tentei aplicar ao máximo Deno.json, JSR, imports modernos, Deno Deploy etc. em um projeto de monorepo com Next.js, Hono e pacotes privados, e compartilho a experiência. O Hono funcionou bem e de forma limpa, mas o Next.js não, e também surgiram casos em que problemas de tipagem quebravam de forma sutil. Lembro que a escolha do destino de deploy (Vercel etc.) também foi um problema. Compartilho um pequeno problema que enfrentei como exemplo neste link da issue. Já o Bun, embora não fosse tão limpo de usar quanto o Deno, exigia menos reflexão e passava a impressão de simplesmente “funcionar”. Ainda assim, o Bun também não é perfeito, como no caso de a Vercel não oferecer suporte ao runtime do Bun

  • O conselho foi que a stack escolhida ainda era centrada em npm, especialmente em um ambiente com muitos pacotes npm privados, então era forçar demais. Acho que o lado mais atraente da abordagem do Deno está em escolher por conta própria uma stack amigável ao Deno ou ao ESM. Tive uma boa experiência usando Lume ou mirando no Deno Deploy. (A pontuação do JSR também ajuda a explorar bibliotecas interessantes com forte compatibilidade com ESM.) Claro, na prática é difícil começar com uma stack totalmente nova, e o investimento existente em Next.js etc. também é grande, então é pesado recomendar Deno. Mas vejo que as vantagens do Deno aparecem quando se começa do zero com todo um conjunto de ferramentas Deno-native e ESM-native. Como referência, a compatibilidade com npm do Deno vem melhorando aos poucos, e as notas de lançamento do 2.4 também trazem melhorias relacionadas. Em ambiente full-stack, uma abordagem priorizando package.json em vez de deno.json tem compatibilidade melhor, então, mesmo que no longo prazo você avance para deno.json, também recomendo uma configuração baseada em package json

  • Ao usar o Deno em modo de compatibilidade com npm, a impressão é de que ele funciona surpreendentemente bem. É muito parecido com a forma de usar o Bun. Se você executar deno install em um diretório com package.json, ele cria um node_modules enxuto, e com o comando deno task something é possível executar scripts definidos no package.json. Mas a forma própria do Deno muitas vezes consumia muito tempo e era frustrante, e quando eu tentava voltar ao ambiente node/npm, só surgiam mais dores de cabeça. Em resumo, usar Deno junto com package.json é mais tranquilo

  • No começo eu fui all-in no Deno, mas havia tantos probleminhas que foi difícil. Em comparação, o Bun funciona bem sem exigir muita atenção

• As pessoas tendem a subestimar a compatibilidade do Deno com Node. Espero que a adoção da variável de ambiente compat ajude na difusão. Seria ainda mais prático se comandos como denon a ativassem automaticamente

  • Na minha experiência, a compatibilidade do Deno com Node ficou abaixo do esperado. Levei cerca de 1 hora para migrar um projeto simples de 100~200 linhas para Deno, quando o normal seria terminar em 5~10 minutos. Alguns métodos do Node não eram suportados, a documentação relacionada era fraca, e até recursos básicos precisavam ser baixados diretamente de URLs obscuras. Na hora de portar a suíte de testes, acabei desistindo. Especialmente a transição de CommonJS (CJS) para ESM foi muito mais dolorosa do que eu imaginava, e de forma alguma dá para converter tão facilmente quanto a documentação oficial do Deno sugere. Tive a experiência de não conseguir portar uma biblioteca inteira

  • Antes eu era bem positivo em relação ao Deno, mas agora não vejo um motivo claro para usá-lo no lugar do Bun

• Há elogios à lista de mudanças recentes do Deno. Estou usando Deno com satisfação para escrever scripts aleatórios e glue code (para machine learning etc. uso python/uv) e tenho expectativas para o suporte futuro a gRPC e também para o comando de bundle

• Ainda acho curioso que o Deno ainda não funcione direito no FreeBSD. O binding do V8 baseado em Rust ainda não foi portado

  • Fico curioso para saber quantos usuários de FreeBSD realmente existem entre desenvolvedores JavaScript modernos

  • Antigamente, a portabilidade entre Unix era uma medida da limpeza do código, mas hoje em dia a compatibilidade entre vários sistemas Unix parece não receber tanta ênfase, o que me surpreende

  • Parece estar registrado nos ports do FreeBSD

  • É bem compreensível não investir muito esforço em suporte ao FreeBSD

• Uma opinião é que o motivo de o Deno não ser mais amplamente usado em produção é a ausência de um banco de dados padronizado de vulnerabilidades. Dá para contornar com compatibilidade 100% com npm, mas aí a maioria dos pacotes populares do Deno fica fora do escopo. No fundo, o desafio é não haver um gerenciador central de pacotes (por design). Pergunta-se se houve algum avanço nessa área

  • Em resposta, se a ausência de um banco de dados de vulnerabilidades realmente fosse um grande problema em produção, então C/C++ também não poderiam ser usados. Na prática, C/C++ verificam problemas de segurança consultando bancos como CVE/GHSA, que são neutros em relação à linguagem. Como referência, em C muitas vezes as pessoas simplesmente vendorizam arquivos externos e nem rastreiam versões. Além disso, existe o arquivo deno.lock, então quem se preocupa com isso pode usá-lo para verificar bancos de vulnerabilidades com base nas versões em uso

  • A estrutura de importar pacotes diretamente de URLs (GitHub etc.) é parecida com a do Go, então o mesmo problema também se aplicaria ao Go

• Gostei que o subcomando bundle foi adicionado novamente. Fico satisfeito por não precisar de soluções alternativas incômodas

• Foi surpreendente adotarem esbuild para bundling em vez do Rolldown baseado em Rust. O Rolldown está prestes a chegar à v1

  • O esbuild hoje é muito estável e maduro, enquanto o Rolldown ainda está mudando rapidamente, então escolher esbuild é o caminho mais seguro

• Gosto muito da direção do Deno e penso que o Node deveria ter sido assim desde o começo. O que me preocupa, porém, é o Deno acabar seguindo sem mudanças o “hype” das concorrentes

  • Também dá para pensar que o próprio Deno vinha sendo visto como um concorrente do Node.js movido por “hype” durante todo esse tempo

• Continuo ouvindo avaliações positivas sobre o Deno. Isso até está me fazendo pensar em experimentar js

  • Hoje em dia, começar direto com TS também é uma boa escolha

• Apoio o Deno do ponto de vista de segurança, mas compartilho a sensação de incômodo com o fato de o site oficial recomendar aos usuários uma instalação no estilo curl mywebsite.com/foo.sh | sh. Claro, cada um tem um nível diferente de tolerância ao risco, mas pelo menos ao baixar o arquivo e executá-lo depois, você ou o antivírus podem inspecioná-lo. O ecossistema Node/Deno + npm, por natureza, já exige bastante confiança. O guia oficial também oferece a opção npm install -g deno além de curl | sh, e o npm ao menos faz verificação mínima de integridade de arquivos e uma checagem simples de malware, então parece relativamente mais seguro. O site deno.land, ainda que pareça seguro no nível do codebase, não pode ser garantido 100% do ponto de vista operacional, então vejo curl | sh como algo que não é uma boa prática de segurança

  • Não concordo com essa lógica. A maioria dos scripts de instalação no fim só serve para baixar e executar binários de centenas a milhões de linhas feitos pelo mesmo autor. Se você não confia minimamente no autor a ponto de supor que o servidor possa distribuir malware só para certos IPs, então ele também poderia embutir malware no binário, e nesse caso você simplesmente não deveria usar o projeto. A polêmica sobre curl | sh parece ter se espalhado por ser um argumento fácil e repetível, enquanto o verdadeiro problema de segurança é revisar milhões de linhas de código. Se o nível de preocupação inclui até ataques MITM por órgãos governamentais, então a única saída seria cortar toda confiança externa da internet

  • Aponta-se a dificuldade de onboarding de novos usuários. Mesmo que se recomende usar npm, o npm precisa estar instalado antes, e o site oficial do npm ensina a instalar o nvm, que por sua vez também usa curl | sh. Então, no fim, a rota via npm também esbarra indiretamente no mesmo problema

  • Na discussão sobre se npm install -g deno é de fato mais seguro que curl | sh, o ponto central depende de “qual lado um hacker conseguiria invadir com mais facilidade: o servidor do npm ou o servidor próprio?”. Se não há como ter certeza de que o servidor próprio não foi comprometido, também não há por que dizer que curl | sh é menos seguro do que npm install. No fim, do ponto de vista de segurança, os dois métodos podem ser igualmente vulneráveis, então, numa visão extrema, o próprio uso da internet é o problema

  • Uma crítica diz que a implementação do sandbox do Deno tem cara de tecnologia dos anos 90, e que usá-lo não seria um bom hábito de segurança

  • Fica a curiosidade se já existiu algum caso real em que um ataque por meio do método de instalação curl | sh tenha funcionado na prática