Bun v1.0.0 - toolkit all-in-one rápido para executar, compilar, testar e depurar JavaScript e TypeScript

• Bun 1.0 executa, compila, testa e depura JavaScript e TypeScript em uma única ferramenta, com estabilidade e pronto para produção
• Com o objetivo de ser uma substituição do Node.js, oferece suporte a APIs e resolução de módulos do Node, como fs, path, net, __dirname, process e resolução de node_modules, e aplicações baseadas em Express, Koa, Hono, além de Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart e Vite funcionam no Bun
• A primeira build nativa para Windows está sendo disponibilizada, mas é altamente experimental; no momento, suporta apenas o runtime JavaScript, e o gerenciador de pacotes, o test runner e o bundler estão desativados
• Entre as mudanças desde o Bun 0.8, foram adicionados suporte a Next.js, Astro e Nest.js, e o comando descontinuado bun dev foi removido, passando agora a executar o script "dev" do package.json
• Entre as novas APIs do Node.js suportadas estão child_process.fork() e IPC, fs.cp(), fs.cpSync(), fs.watchFile(), fs.unwatchFile() e Unix socket em node:http
• Um transpiler de JavaScript embutido no runtime permite executar arquivos .js, .ts, .cjs, .mjs, .jsx e .tsx sem dependências adicionais
• Suporta ESM e CommonJS ao mesmo tempo, permitindo usar import e require() no mesmo arquivo sem depender de extensão de arquivo ou da configuração "type": "module" no package.json
• APIs padrão da Web como fetch, Request, Response, WebSocket e ReadableStream vêm embutidas, permitindo uso sem pacotes como node-fetch e ws
• O hot reloading pode ser usado com a opção --hot, e Bun.serve() também passa a ser alvo de hot reloading
• A API do Bun fornece Bun.file(), Bun.write(), Bun.serve(), bun:sqlite e Bun.password, cobrindo entrada e saída de arquivos, servidor HTTP/WebSocket, SQLite, hash e verificação de senhas com bcrypt e argon2
• O gerenciador de pacotes oferece bun install, bun add, bun remove e bun update, em um modo compatível com npm que lê o package.json e grava em node_modules
• O test runner bun:test fornece uma API compatível com Jest e remapeia internamente imports de @jest/globals e vitest para bun:test
• O bundler oferece suporte a bundling e minify de JavaScript e TypeScript, além de uma API de plugins compatível com esbuild e JavaScript macros que executam funções JavaScript no momento do bundle para inserir valores inline

[GN⁺]

Opiniões no Hacker News

• Estou participando do desenvolvimento do Bun. Se tiverem perguntas, posso responder
  Seria bom se um moderador trocasse o link para o post do blog, porque ele explica melhor do que a página de releases do GitHub
  Post do blog: https://bun.sh/blog/bun-v1.0

  • Troquei a partir de https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0

• O que mais me impressiona é poder usar import e require() no mesmo arquivo, sem se preocupar com .js/.cjs/.mjs ou "type": "module"
  Sem isso, o ecossistema Node.js está quase completamente quebrado, e o Bun parece que pode salvá-lo. Para mim, o mais incrível no Bun não é o desempenho, mas as escolhas pragmáticas e amigáveis ao desenvolvedor que Jarred vem fazendo de forma consistente

  • Esse problema já é antigo, e tenho dúvidas de que o Bun tenha “resolvido” isso mais do que outras ferramentas
    Ele apenas escolheu outro compromisso, e o resultado provavelmente é que outro conjunto de pacotes não vai funcionar. Fico curioso se há alguma base para acreditar que o Bun descobriu um segredo que as outras ferramentas não conseguiram resolver
  • Quando o Node propôs separar a sintaxe, defendi que ele desse suporte a esse tipo de abordagem, e fico muito feliz que o Bun tenha adotado isso
    Para mim, esse é o jeito certo. O ecossistema dividido do Node causou um grande dano à linguagem e ao runtime como um todo
  • A cada poucos anos surge algo em que preciso usar bastante JavaScript e, quando mergulhei nisso de novo recentemente, perdi horas por causa de import versus require
    Se você não está usando uma app React ou uma solução pronta, o ecossistema moderno de JS é realmente doloroso, especialmente para quem está criando uma biblioteca pequena. Nem consigo imaginar o quanto isso deve ser difícil e enlouquecedor para quem está começando
    Só o fato de o Bun resolver esse problema já é motivo suficiente para eu experimentá-lo. Eu não esperava sentir esse tipo de expectativa por mais um runtime ou ferramenta de build de JS, e estou animado porque a equipe do Bun pode deixar meu dia um pouco mais são
  • Há quase um ano venho criando projetos com módulos por padrão. Depois que a estratégia de resolução bundler saiu no TypeScript 5.0, os últimos seis meses foram em geral tranquilos
    Tive problemas muito raramente, mas até os projetos corrigirem, contornei com pnpm patch e ajustes nos metadados. Dá para dizer que 2023 é o ano dos módulos, e a água está boa
  • Concordo. A esta altura eu deveria ser especialista em JavaScript, mas nada me faz sentir tão burro quanto navegar por type: module e .js/.cjs/.mjs/.ts
    Em apps de produção, obviamente é preciso ter clareza sobre o que se usa, mas em prototipagem o comportamento permissivo do Bun permite escrever o código primeiro e se preocupar com o resto depois

• Acho que daria para usar uma frase melhor do que substituto drop-in em uma versão 1.0 que decidiu não implementar todo o node:
  Fiquei bem decepcionado ao ver que os dois primeiros projetos que tentei não eram substituíveis de forma drop-in, e agora desconfio de toda a comunicação do Bun
  Para contextualizar, ambos os projetos usam osc, que precisa de dgram. Encontrei um ticket de acompanhamento de pedido de recurso de 9 meses atrás, mas não havia plano de implementação, e pesquisar por dgram nesta página de anúncio não retorna nada
  Como sugestão rápida, seria bom listar os módulos sem suporte no Bun 1.0 e incluí-los na seção de compatibilidade com Node.js
  Edição: encontrei a documentação de suporte ao Node — https://bun.sh/docs/runtime/nodejs-apis . Seria bom linká-la nas notas de lançamento
  Olhando por alto, parece haver cerca de 17 módulos implementados, 17 parcialmente implementados e 7 não implementados

  • A versão real parece mais próxima de 1.0.0-beta do que de 1.0.0
    Acabei de instalar a v1.0.0 e executei bun repl, mas ele falhou com código de saída 1; descobri que o REPL tenta usar a porta 3000, que no meu ambiente já estava em uso. Pelos bugs reportados no GitHub, parece que há muitos probleminhas desse tipo, então acho que é preciso manter certo ceticismo em relação a todas as afirmações
    Mesmo assim, fiquei profundamente impressionado com a velocidade e o resultado. Não imaginava que este projeto chegaria até aqui tão rápido; achava que levaria muito mais tempo. Em comparação, o Deno começou bem antes e agora parece estar bem atrás, então pretendo usar o Bun em projetos pessoais
  • O importante não é quantos são, mas quais módulos são
    Como relato anedótico, estamos testando o Bun em uma aplicação grande, com clientes existentes na casa dos milhões, e até agora o único problema não foi o Bun em si, mas o fato de patch-package ainda não dar suporte ao arquivo de lock bun.lockb
    O Bun é, sem dúvida, muito mais rápido que o Yarn. E digo isso como alguém que gosta muito do Yarn
  • A seção de compatibilidade com Node.js já diz isto
    “Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
    A lista detalhada especifica os módulos sem suporte
  • Concordo com este comentário. Eu estava muito animado e queria experimentá-lo, mas ele não conseguiu executar a maioria dos nossos projetos
    Não conseguimos usar o AWS SDK v3 por causa de erros ao fazer parsing da resposta, e como node:crypto não está totalmente implementado, não conseguimos usar coisas que dependem de octokit ou jsonwebtoken. Não dá para rodar os testes porque jest.resetAllMocks() não existe, e em outro projeto o bun test nem chegava a executar, dizendo que a chamada a uma biblioteca compartilhada estava incorreta
    Então meu fluxo local virou “tentar executar com Bun e, se falhar, executar de novo com Node”. Pelo menos dá para usá-lo como substituto do npm, mas ainda é difícil imaginar usá-lo para rodar serviços. Quando funciona, é realmente impressionante, então estou animado com o futuro; mas, se o ponto de venda é compatibilidade com Node, acho difícil chamar isso de 1.0

• Fico curioso se houve alguma intenção de mover o chat da comunidade para uma plataforma que não seja o Discord
  O Discord já foi mencionado várias vezes no HN por problemas de acessibilidade, privacidade e dependência de uma plataforma proprietária, e também não parece combinar muito bem com o espírito open source. [1] também vale a leitura
  [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

  • Mesmo que seja importante não usar o Discord, parece pouco provável que isso mude
    Nos comentários do anúncio do Bun 0.6, uma pergunta parecida recebeu tantos downvotes que quase foi sinalizada: https://news.ycombinator.com/item?id=35970869
    Nos comentários do anúncio do Bun 0.8, a mesma pergunta quase não recebeu atenção, e a reação foi algo como “outros projetos também usam…”: https://news.ycombinator.com/item?id=37244294
  • A acessibilidade do Discord melhorou bastante. Até o usuário de leitor de tela citado na seção de fontes desse artigo concorda que, recentemente, a acessibilidade do Discord ficou melhor e que mais pessoas cegas estão usando a plataforma
    Sinceramente, o Discord é um bom lugar para projetos de software livre e open source manterem sua comunicação. As alegações do texto de que “ao escolher o Discord você legitima a plataforma e tira valor das plataformas FOSS” parecem bem frágeis. O Discord é, de fato, uma plataforma legítima, gratuita, com muitos recursos atraentes e boa acessibilidade. Acima de tudo, escolher o Discord não faz o valor das plataformas de comunicação FOSS desaparecer
    A recomendação de “use IRC” também não faz sentido. IRC é muito difícil de acessar para muitas pessoas que não têm familiaridade com computadores e software
  • Existe alguma alternativa FOSS ao Discord que não custe dinheiro?
  • answeroverflow.com poderia servir como uma solução temporária?

• Bun é baseado em investimento de venture capital, então fico curioso sobre o plano de monetização
  Ao avaliar uma tecnologia nova, considero “a probabilidade de essa tecnologia ainda estar sendo desenvolvida ativamente daqui a N anos”. O Bun precisa ganhar dinheiro de alguma forma; caso contrário, o financiamento vai acabar
  É ótimo que a licença do Bun seja MIT, e isso dá esperança de que o projeto possa não morrer mesmo se a empresa quebrar. Torço para que a empresa dê certo, mas, se eu adotasse o Bun, ficaria curioso sobre quais upsells poderiam aparecer depois

  • O plano de negócios está explicado em https://oven.sh/
    A Oven oferecerá hospedagem serverless muito rápida e integração contínua para apps JavaScript de backend e frontend, e será movida pelo Bun
    Pretende oferecer suporte a frameworks de frontend como Next.js, Vite, SvelteKit e SolidStart, e frameworks de backend como Express, Fastify e NestJS
    O plano é operar seus próprios servidores na edge de data centers ao redor do mundo, e a Oven quer integrar toda a stack JavaScript de ponta a ponta, até o hardware, para criar novas possibilidades
  • Como é um bundler, acho que vão ganhar dinheiro com hospedagem de apps JS em algo como bun deploy
    É uma estratégia comum: primeiro conseguir adoção em massa entre desenvolvedores e depois conduzi-los suavemente para a própria hospedagem de aplicações
  • Antigamente havia um servidor de desenvolvimento HMR bacana chamado Pundle. Era rápido o bastante para responder instantaneamente, mas também era um projeto mantido por uma pessoa em um país pobre
    Sofri tanto tentando acompanhar o projeto paralelo de uma única pessoa que migrei tudo para Rollup e nunca olhei para trás
    As preocupações com um projeto financiado por venture capital e com um projeto paralelo aleatório claramente são diferentes, mas o risco final em ambos é: “o que acontece se quem criou isso não puder mais me dar suporte?”
  • Acho que deve seguir o caminho do NextJS/Vercel ou do Deno/Deploy, e também não descartaria uma mudança de licença
    É aquele modelo de divulgar tudo como “open source” para obter relatórios de bugs gratuitos, contribuições, marketing e adoção, e depois empurrar para um produto comercial

• A proposta de substituir a confusão em camadas das ferramentas baseadas em Node é muito atraente
  Porque poderia reduzir node, ts-node, nodemon, tsc, jest, ts-jest, webpack, Babel, duas especificações de módulos incompatíveis, a confusão do UMD, três gerenciadores de pacotes e a explosão de arquivos de configuração causada por tudo isso
  O ecossistema de ferramentas em torno do JavaScript é, sem dúvida, a maior dor, e transforma ES6 + TypeScript, que originalmente é uma linguagem bastante competente e agradável, em puro trabalho braçal. Espero que o Bun consiga resolver isso
  Imagino que seja parecido com passar de CMake para Cargo

• O post do blog mostra de forma muito convincente a proposta de valor de um software tudo em um mais simples
  Hoje em dia me atraem mais softwares “baterias incluídas” do que “traga tudo você mesmo”, então estou ansioso para testar o Bun
  Parece uma versão em runtime das ferramentas Rome, que tentavam substituir vários softwares por uma única alternativa mais rápida. O Rome fracassou e passou a ser OSS com uma nova equipe. Espero que o Bun tenha mais sucesso, mas certamente é um problema difícil de resolver

  • Concordo com a abordagem “baterias incluídas”. Para começo de conversa, se o ecossistema do Node.js fosse harmonioso, essa abordagem não seria necessária
    Quando se possui e controla diretamente o hardware e o sistema operacional, como a Apple, é possível otimizar o sistema em profundidade e também dar a tranquilidade de que todos os dispositivos funcionam de forma integrada. Um conjunto de ferramentas tudo em um reduz o peso de sair correndo atrás da solução perfeita e permite usar a solução que já está à sua frente

• Para quem já usou tanto Bun quanto Deno, gostaria de ouvir qual dos dois é, na prática, o sucessor do Node mais convincente
  O site do Bun afirma que ele tem desempenho muito melhor que o Deno, e fico curioso se isso também é verdade na prática. Se for, também gostaria de entender por quê. O Deno parece ter objetivos parecidos
  Também fico curioso se há grandes diferenças filosóficas entre os dois projetos. Por exemplo, não sei se é algo como o Bun querer reimplementar todo tipo de coisa, enquanto o Deno quer um novo jeito pós-Node. Alguém já usou bastante os dois?

  • Nenhum dos dois me atrai tanto assim, mas, antes de tudo, fico me perguntando por que precisamos de um sucessor do Node
    Tanto Bun quanto Deno são ferramentas baseadas em investimento de venture capital, então tenho uma desconfiança básica quanto à monetização e à sustentabilidade
    O principal argumento de venda do Bun parece ser desempenho, mas eu raramente tive grandes problemas de desempenho com Node. Ele não é absurdamente rápido, mas é muito mais provável esbarrar em limitações de entrada/saída do que na velocidade do Node
    O principal argumento de venda do Deno era ser, em vários aspectos, um “Node feito direito”, com empacotamento melhor, uso pleno de ES6 etc., e esse argumento me atraía, mas parece que eles desistiram da tentativa de criar um novo ecossistema e foram para o caminho de adicionar compatibilidade com Node
    Ao mesmo tempo, melhorias recentes no próprio Node, como o test runner nativo e o suporte embutido a .env, são animadoras. Por isso, é difícil encontrar um motivo forte para usar Bun ou Deno e, mesmo que eu mude, preciso de um caminho concreto para voltar ao Node caso as ferramentas da nova geração se tornem insustentáveis
  • Essas ferramentas são jovens demais para alguém dizer que realmente as usou por muito tempo
    O Bun tenta agrupar tudo e tornar tudo muito rápido, mantendo ao máximo a compatibilidade com Node. Ele não abandona o ecossistema existente
    O Deno adotou uma postura muito confrontadora em relação ao ecossistema Node, e agora está adicionando suporte de volta
    Do ponto de vista de sucessor, vejo o Bun como a única opção, porque ele tenta inovar com novos recursos mantendo a compatibilidade com Node
  • Não sou um usuário avançado e mexi principalmente com Deno
    O Deno me parece mais um runtime alternativo ao Node com segurança como princípio máximo, além de suporte embutido a TypeScript e JSX e ferramentas como linter. Ele também é baseado no V8. Parece estar mais próximo da forma que Ryan Dahl passou a achar, tardiamente, que o Node deveria ter tido
    O Bun é tecnicamente baseado no WebKit, embora eu não saiba exatamente por quê, e parece não ser apenas um runtime, mas uma ferramenta all-in-one melhor. Ele também oferece compatibilidade básica com frameworks existentes. Até pouco tempo atrás, o Deno não era compatível com npm, e também fico curioso se essa era a intenção desde o começo ou se foi uma mudança de direção em andamento
  • Somos uma equipe full-stack TypeScript e mantemos cerca de 50 bibliotecas internas e cerca de 500 mil linhas de TypeScript
    No mês passado, testamos Deno e Bun como runtimes alternativos. Em resumo, em uma base de código com certa complexidade, o Bun quase sempre funciona e o Deno quase sempre não funciona
    Agora rodamos todos os testes tanto em Node.js quanto em Bun, e desistimos da tentativa de adotar o Deno
  • Se minha memória não falha, o Bun, ao contrário de Node/Deno, não oferece suporte a Windows
    Correção: parece que isso está mudando. Obrigado pela correção

• Originalmente, o plano era lançar ontem, mas havia uma falha em um teste de streaming do corpo de fetch() que precisava ser corrigida
  O post do blog não deveria ser publicado até o Bun 1.0 aparecer no GitHub, mas o link estava acessível publicamente e havia um bug que não escondia o rascunho no feed RSS
  O bug real não estava no streaming do corpo de fetch(), mas nos bindings do JavaScriptCore ao obter uma propriedade de um objeto em que a propriedade podia não estar definida. Parte do código só verificava se o valor era um JSCell, sem checar se era um objeto; JSCell normalmente é um objeto, mas coisas como símbolos ou BigInt não são JSObject
  Thread de ontem: https://news.ycombinator.com/item?id=37424724

  • Seria bom atualizar a seção de instalação da documentação para Linux, pois estão faltando DEB/RPM
    Como dica adicional, para instalações do tipo “baixar da internet em vez de usar o repositório da distribuição”, poderiam fornecer exemplos de playbooks/conjuntos de tarefas do Ansible com checksums apropriados, como SHA-256. O mesmo vale para Puppet, embora seja um pouco mais complexo
    Isso poderia aliviar um pouco o trabalho dos administradores de sistemas e, se quiserem dar um nome, poderiam chamar de SAX, ou seja, experiência do administrador de sistemas

• Se o Bun consegue executar e empacotar apps TypeScript React de forma nativa, fico me perguntando qual é a vantagem de usar Vite.js por cima dele
  O guia do site oficial mostra como usar Bun + Vite.js ao criar um app TypeScript React, o que deixa confuso. [1]
  Há uma issue relacionada também no GitHub. [2]
  Será que o Vite.js fica responsável por cenários mais complexos ou casos de uso avançados que o Bun não consegue lidar? Meu uso do Vite.js se resume a começar com uma configuração básica TS+React e fazer o build, então talvez eu esteja deixando passar algo
  [1] https://bun.sh/guides/ecosystem/vite
  [2] https://github.com/oven-sh/bun/issues/250

  • O Vite ainda usa Node, esbuild, swc, tsc etc. para partes pelas quais ele próprio não é diretamente responsável
    Ainda não tenho experiência usando Bun, mas entendo que dá para usar Bun em vez de Node para rodar o servidor de desenvolvimento local, usar Bun no lugar de esbuild ou tsc, Rollup ou uma combinação deles para bundling, e usar Bun no lugar de Babel e TypeScript para transformação
    O que o Vite oferece é uma configuração que facilita o desenvolvimento de aplicações front-end e proporciona uma boa experiência do desenvolvedor no trabalho local
  • Só vi o Vite sendo usado com Bun para HMR
    Ainda acho que a complexidade de configuração faz com que combinar os dois não seja tão bom assim
  • Pedir que as pessoas adotem um ecossistema inteiro de uma vez é uma carga grande
    Compatibilidade com o ecossistema existente é um objetivo central do Bun, então a ideia é permitir que as pessoas comecem a usá-lo diretamente em bases de código existentes e o adotem gradualmente em mais partes
  • Parece possível aproveitar o ecossistema de plugins do Vite. Coisas como PostCSS, Tailwind e Terser
    E, como a maioria dos novos meta-frameworks, como Nuxt, SvelteKit, Astro, SolidStart e Qwik, roda sobre o Vite, isso pode abrir um caminho de adoção para o Bun
  • Isso é parecido com perguntar por que Vite é necessário se já existe tsc
    Eu diria que o Bun não “executa apps TypeScript React” tanto assim; ele mais oferece transformação JSX/TSX de forma nativa