- Bun 1.0 gère l’exécution, la compilation, les tests et le débogage de JavaScript et TypeScript dans un seul outil, et est stabilisé et prêt pour la production
- Il vise à remplacer Node.js en prenant en charge les API Node et la résolution de modules, notamment
fs,path,net,__dirname,processet la résolution denode_modules; les applications basées sur Express, Koa, Hono ainsi que Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart et Vite fonctionnent avec Bun - Une build native pour Windows est proposée pour la première fois, mais elle reste très expérimentale ; elle ne prend actuellement en charge que le runtime JavaScript, tandis que le gestionnaire de paquets, le test runner et le bundler sont désactivés
- Parmi les changements depuis Bun 0.8, la prise en charge de Next.js, Astro et Nest.js a été ajoutée, et la commande
bun dev, qui était dépréciée, a été supprimée ; elle exécute désormais le script"dev"depackage.json - Les nouvelles API Node.js prises en charge incluent
child_process.fork()et l’IPC,fs.cp(),fs.cpSync(),fs.watchFile(),fs.unwatchFile(), ainsi que les sockets Unix denode:http - Le runtime intègre un transpileur JavaScript, ce qui permet d’exécuter des fichiers
.js,.ts,.cjs,.mjs,.jsxet.tsxsans dépendance supplémentaire - ESM et CommonJS sont pris en charge simultanément, permettant d’utiliser
importetrequire()dans un même fichier sans extension de fichier spécifique ni réglage"type": "module"danspackage.json - Des API Web standard comme
fetch,Request,Response,WebSocketetReadableStreamsont intégrées, utilisables sans paquets commenode-fetchouws - L’option
--hotpermet d’activer le hot reloading, etBun.serve()est également pris en charge par ce mécanisme - Les API Bun
Bun.file(),Bun.write(),Bun.serve(),bun:sqliteetBun.passwordfournissent les entrées/sorties fichier, les serveurs HTTP/WebSocket, SQLite, ainsi que le hachage et la vérification de mots de passe avec bcrypt et argon2 - Le gestionnaire de paquets propose
bun install,bun add,bun removeetbun update, avec une compatibilité npm consistant à lirepackage.jsonet à écrire dansnode_modules - Le test runner
bun:testfournit une API compatible avec Jest, et remappe en interne les imports@jest/globalsetvitestversbun:test - Le bundler prend en charge le bundling et la minification de JavaScript et TypeScript, propose une API de plugins compatible avec esbuild, ainsi que des macros JavaScript qui exécutent des fonctions JavaScript au moment du bundling pour intégrer des valeurs en ligne
1 commentaires
Avis sur Hacker News
Je participe au développement de Bun. Si vous avez des questions, je peux y répondre.
Ce serait bien que les modérateurs remplacent le lien par l’article de blog, car il explique mieux les choses que la page de release GitHub.
Article de blog : https://bun.sh/blog/bun-v1.0
Ce qui m’impressionne le plus, c’est qu’on puisse utiliser
importetrequire()dans le même fichier, sans se soucier de.js/.cjs/.mjsni de"type": "module".Sans ça, l’écosystème Node.js est presque complètement cassé, et Bun pourrait bien le sauver. À mes yeux, ce qu’il y a de plus remarquable dans Bun, plus que les performances, ce sont les choix pragmatiques et favorables aux développeurs que Jarred a constamment faits.
Il a simplement choisi un autre compromis, avec pour conséquence probable qu’un autre ensemble de packages ne fonctionne pas. Je serais curieux de savoir s’il y a des raisons de penser que Bun a trouvé le secret que les autres outils n’ont pas réussi à découvrir.
Pour moi, c’est la bonne approche. L’écosystème fragmenté de Node a fait beaucoup de dégâts à l’ensemble du langage et du runtime.
importcontrerequire.Si vous n’utilisez pas une appli React ou une solution clé en main, l’écosystème JS moderne est vraiment pénible, surtout quand on crée une petite bibliothèque. Je n’imagine même pas à quel point ça doit être difficile et frustrant pour les débutants.
Le simple fait que Bun résolve ce problème suffit à me donner envie de l’essayer. Je ne pensais pas pouvoir ressentir ce genre d’enthousiasme pour un autre runtime JS ou outil de build, et j’ai hâte que l’équipe de Bun rende mes journées un peu plus supportables.
bundlerdans TypeScript 5.0, les six derniers mois se sont globalement bien passés.Il y a eu de très rares problèmes, mais en attendant que les projets les corrigent, je les ai contournés avec
pnpm patchet des modifications de métadonnées. On peut considérer 2023 comme l’année des modules, et l’eau est bonne.type: moduleet.js/.cjs/.mjs/.ts.Dans une appli de production, il faut évidemment être clair sur ce qu’on utilise, mais pour du prototypage, le comportement permissif de Bun permet d’écrire d’abord le code et de s’occuper du reste plus tard.
Pour une release 1.0 qui a décidé de ne pas implémenter tout
node:, je me demande s’il n’y aurait pas une meilleure formulation que remplacement drop-in.J’ai été très déçu de constater que les deux premiers projets que j’ai essayés n’étaient pas remplaçables tels quels, et cela me pousse désormais à douter de toute la communication de Bun.
Pour le contexte, les deux projets utilisent
osc, qui a besoin dedgram. J’ai trouvé un ticket de suivi de demande de fonctionnalité datant d’il y a 9 mois, mais aucun plan d’implémentation, et une recherche dedgramsur la page d’annonce ne donne rien.Petite suggestion rapide : ce serait bien de lister explicitement les modules non pris en charge dans Bun 1.0 et de les mettre dans la section de compatibilité Node.js.
Modification : j’ai trouvé la documentation sur la prise en charge de Node — https://bun.sh/docs/runtime/nodejs-apis . Ce serait bien de la lier dans les notes de release.
À vue de nez, côté modules, il semble y en avoir environ 17 implémentés, 17 partiellement implémentés et 7 non implémentés.
1.0.0-betaqu’à1.0.0.Je viens d’installer la v1.0.0 et de lancer
bun repl, qui a échoué avec le code de sortie 1 ; il s’est avéré que le REPL essaie d’utiliser le port 3000, déjà occupé dans mon environnement. À voir les bugs signalés sur GitHub, il y a probablement pas mal de petits problèmes de ce genre, donc il faut garder un certain scepticisme face à toutes les affirmations.Cela dit, je suis très impressionné par la vitesse et par le résultat. Je ne pensais pas que ce projet arriverait jusque-là aussi vite ; je m’attendais à ce que cela prenne beaucoup plus longtemps. Par comparaison, Deno a commencé bien plus tôt, mais donne aujourd’hui l’impression d’être loin derrière, donc je pense essayer Bun pour des projets personnels.
Pour donner un exemple, nous testons Bun sur une grosse application existante avec des millions de clients, et jusqu’ici le seul problème ne vient pas de Bun lui-même, mais de
patch-package, qui ne prend pas encore en charge le fichier de verrouillagebun.lockb.Bun est sans aucun doute beaucoup plus rapide que Yarn. Et je dis ça en aimant vraiment Yarn.
“Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
La liste détaillée précise les modules non pris en charge.
Nous ne pouvions pas utiliser AWS SDK v3 à cause d’une erreur lors du parsing de la réponse, et comme
node:crypton’est pas entièrement implémenté, nous ne pouvions pas utiliser ce qui dépend deoctokitoujsonwebtoken. L’absence dejest.resetAllMocks()nous empêchait de lancer les tests, et dans un autre projet,bun testne se lançait même pas, en signalant un mauvais appel à une bibliothèque partagée.Du coup, notre flux de travail local est : “essayer avec Bun, puis relancer avec Node si ça échoue”. Au minimum, on pourra s’en servir comme remplacement de npm, mais j’ai encore du mal à l’imaginer pour exécuter des services. Quand ça marche, c’est vraiment impressionnant, donc l’avenir est prometteur, mais si l’argument de vente est la compatibilité Node, j’ai du mal à appeler ça une 1.0.
Je me demande s’ils ont envisagé de déplacer le chat de la communauté vers une plateforme autre que Discord
Discord a été mentionné plusieurs fois sur HN à cause de problèmes d’accessibilité, de confidentialité et de dépendance à une plateforme propriétaire, et ne semble pas très aligné avec l’esprit open source. [1] mérite aussi d’être consulté
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
Dans les commentaires de l’annonce de Bun 0.6, une question similaire avait été downvotée au point d’être presque signalée : https://news.ycombinator.com/item?id=35970869
Dans les commentaires de l’annonce de Bun 0.8, la même question n’avait presque pas suscité d’intérêt, avec des réactions du type « les autres projets l’utilisent tous aussi… » : https://news.ycombinator.com/item?id=37244294
Honnêtement, Discord est un bon endroit pour héberger les communications d’un projet de logiciel libre et open source. Les arguments de l’article selon lesquels « choisir Discord légitime cette plateforme et retire de la valeur aux plateformes FOSS » semblent assez fragiles. Discord est réellement une plateforme légitime, gratuite, avec beaucoup de fonctionnalités attractives, et une bonne accessibilité. Surtout, choisir Discord ne fait pas disparaître la valeur des plateformes de communication FOSS
Dire « utilisez IRC » n’est pas non plus pertinent. IRC est très difficile d’accès pour beaucoup de personnes qui ne sont pas à l’aise avec les ordinateurs et les logiciels
Bun est financé par du capital-risque, et je me demande quel est son plan de monétisation
Quand je regarde une nouvelle technologie, j’évalue « la probabilité que cette technologie soit encore développée activement dans N années ». Bun doit gagner de l’argent d’une manière ou d’une autre ; sinon, le financement finira par s’arrêter
Le fait que la licence de Bun soit MIT est excellent, et donne l’espoir que le projet ne mourra pas même si l’entreprise disparaît. J’espère que l’entreprise réussira, mais si j’adoptais Bun, je me demanderais quelles ventes additionnelles pourraient arriver plus tard
Oven proposera un hébergement serverless très rapide et de l’intégration continue pour les apps JavaScript backend et frontend, et sera propulsé par Bun
Il devrait prendre en charge des frameworks frontend comme Next.js, Vite, SvelteKit et SolidStart, ainsi que des frameworks backend comme Express, Fastify et NestJS
Le plan consiste à exploiter leurs propres serveurs en edge dans des datacenters du monde entier ; Oven veut intégrer toute la stack JavaScript de bout en bout jusqu’au matériel, pour créer de nouvelles possibilités
bun deployC’est une stratégie courante : obtenir d’abord une adoption massive par les développeurs, puis les orienter en douceur vers leur propre hébergement d’applications
J’ai eu tellement de mal à essayer de suivre le side project d’une seule personne que j’ai tout migré vers Rollup, sans jamais regarder en arrière
Les inquiétudes autour d’un projet financé par du capital-risque et d’un side project aléatoire sont clairement différentes, mais le risque ultime est le même dans les deux cas : « que se passe-t-il si la personne qui l’a créé ne peut plus me soutenir ? »
Le procédé consiste à promouvoir tout cela comme de l’« open source » pour obtenir gratuitement des rapports de bugs, des contributions, du marketing et de l’adoption, puis à pousser les utilisateurs vers un produit commercial
L’idée de pouvoir remplacer l’empilement chaotique des outils basés sur Node est très séduisante
Cela permettrait de réduire
node,ts-node,nodemon,tsc,jest,ts-jest,webpack, Babel, deux spécifications de modules incompatibles, le bazar d’UMD, trois gestionnaires de paquets et l’explosion de fichiers de configuration qui en découleL’écosystème d’outillage autour de JavaScript est clairement la plus grande source de douleur, et transforme ES6 + TypeScript, qui est à l’origine un langage plutôt compétent et agréable, en une corvée totale. J’espère que Bun y arrivera
Cela pourrait ressembler au passage de CMake à Cargo
Le billet de blog présente de façon très convaincante la proposition de valeur d’un logiciel tout-en-un plus simple
Ces jours-ci, je suis plus attiré par les logiciels « batteries incluses » que par ceux où il faut « tout apporter soi-même », donc j’ai hâte d’essayer Bun
Cela ressemble à une version runtime des outils Rome, qui tentaient de remplacer plusieurs logiciels par un seul plus rapide. Rome a échoué et a été transformé en OSS par une nouvelle équipe. J’espère que Bun réussira mieux, mais c’est clairement un problème difficile à résoudre
Quand on possède et contrôle directement le matériel et le système d’exploitation, comme Apple, on peut optimiser le système en profondeur et donner l’assurance que tous les appareils fonctionneront de manière fluide. Une suite d’outils tout-en-un réduit la charge de devoir courir après la solution parfaite, et permet d’utiliser celle qui est déjà sous nos yeux
J’aimerais entendre quelqu’un qui a utilisé à la fois Bun et Deno dire lequel est, en pratique, le successeur de Node le plus convaincant
Le site de Bun affirme qu’il est bien plus performant que Deno, et je me demande si c’est vraiment le cas. Si oui, j’aimerais aussi savoir pourquoi. Deno semble viser des objectifs similaires
Je me demande aussi s’il existe de grandes différences philosophiques entre les deux projets. Par exemple, je ne sais pas si Bun essaie de tout réimplémenter, tandis que Deno voudrait proposer une nouvelle approche après Node. Y a-t-il quelqu’un qui a suffisamment utilisé les deux ?
Bun comme Deno sont des outils financés par du capital-risque, ce qui suscite chez moi des doutes de fond sur leur monétisation et leur pérennité
Le principal argument de vente de Bun semble être la performance, mais je n’ai pas vraiment rencontré de gros problèmes de performance avec Node. Il n’est pas ultra-rapide, mais on a beaucoup plus de chances de se heurter aux limites d’entrée/sortie qu’à la vitesse de Node
Le principal argument de vente de Deno était d’être un « Node bien fait » à plusieurs égards, avec un meilleur packaging, l’usage généralisé d’ES6, etc., et cet argument m’attirait, mais il semble avoir renoncé à créer un nouvel écosystème pour plutôt ajouter la compatibilité avec Node
En même temps, les améliorations récentes de Node, comme son propre runner de tests et la prise en charge intégrée de
.env, sont encourageantes. J’ai donc du mal à trouver une raison forte d’utiliser Bun ou Deno, et même si je changeais, il me faudrait un chemin concret pour revenir à Node si ces outils de nouvelle génération devenaient intenablesBun regroupe tout et rend l’ensemble très rapide, tout en essayant de conserver autant que possible la compatibilité avec Node. Il n’abandonne pas l’écosystème existant
Deno a adopté une position trop antagoniste vis-à-vis de l’écosystème Node, et ajoute maintenant à nouveau sa prise en charge
Du point de vue d’un successeur, je pense que Bun est la seule option. Parce qu’il essaie d’innover avec de nouvelles fonctionnalités tout en conservant la compatibilité avec Node
Deno me semble plus proche d’un runtime alternatif à Node dont le principe prioritaire est la sécurité, avec aussi une prise en charge intégrée de TypeScript et de JSX, ainsi que des outils comme un linter. Il est aussi basé sur V8. Avec le recul, il ressemble à la forme que Ryan Dahl pensait que Node aurait dû prendre
Bun est techniquement basé sur WebKit, mais je ne sais pas exactement pourquoi, et il ressemble non seulement à un runtime, mais à un meilleur outil tout-en-un. Il offre aussi une compatibilité de base avec les frameworks existants. Jusqu’à récemment, Deno n’était pas compatible avec npm, et je me demande si c’était l’intention dès le départ ou si c’est un changement de direction en cours
Le mois dernier, nous avons testé Deno et Bun comme runtimes alternatifs. En résumé, sur une codebase d’une certaine complexité, Bun fonctionne presque toujours et Deno ne fonctionne presque jamais
Nous exécutons maintenant tous nos tests à la fois sur Node.js et Bun, et nous avons abandonné l’idée d’adopter Deno
Correction : on dirait que c’est en train de changer. Merci pour la rectification
La sortie était initialement prévue hier, mais il y avait un échec de test sur le streaming du corps de
fetch()à corrigerL’article de blog ne devait pas être public avant que Bun 1.0 soit disponible sur GitHub, mais le lien était accessible publiquement et il y avait un bug qui empêchait de masquer le brouillon dans le flux RSS
Le vrai bug n’était pas dans le streaming du corps de
fetch(), mais dans les bindings JavaScriptCore qui récupéraient une propriété sur un objet dont la propriété pouvait ne pas être définie. Une partie du code vérifiait seulement que la valeur était unJSCell, sans vérifier qu’il s’agissait d’un objet ; or unJSCellest généralement un objet, mais des choses comme les symboles ou les BigInt ne sont pas desJSObjectFil d’hier : https://news.ycombinator.com/item?id=37424724
Comme piste supplémentaire, pour les installations du type « télécharger depuis Internet plutôt que depuis les dépôts de la distribution », il pourrait être utile de fournir un exemple de playbook/ensemble de tâches Ansible avec un checksum approprié, comme un SHA-256. Même chose pour Puppet, même si ce serait un peu plus complexe
Cela pourrait alléger un peu le travail des administrateurs système, et si vous voulez lui donner un nom, vous pourriez appeler cela SAX, pour expérience administrateur système
Si Bun peut exécuter et bundler nativement des apps TypeScript React, je me demande quel est l’intérêt d’utiliser Vite.js par-dessus
Le guide du site officiel montre comment utiliser Bun + Vite.js pour créer une app TypeScript React, ce qui prête à confusion. [1]
Il y a aussi une issue liée sur GitHub. [2]
Vite.js prend-il en charge des scénarios plus complexes ou des cas d’usage avancés que Bun ne sait pas gérer ? Mon utilisation de Vite.js se limite à démarrer et builder une configuration TS+React de base, donc il se peut que je passe à côté de quelque chose
[1] https://bun.sh/guides/ecosystem/vite
[2] https://github.com/oven-sh/bun/issues/250
Je n’ai pas encore d’expérience avec Bun, mais je comprends qu’on peut utiliser Bun à la place de Node pour lancer le serveur de développement local, Bun à la place d’esbuild ou de tsc, de Rollup ou d’une combinaison de ceux-ci pour le bundling, et Bun à la place de Babel et TypeScript pour la transformation
Ce que Vite apporte, c’est une configuration qui facilite le développement d’applications frontend et offre une bonne expérience développeur en local
Pour l’instant, il y a encore une certaine complexité de configuration, donc je ne pense pas que les combiner soit particulièrement avantageux
La compatibilité avec l’écosystème existant est un objectif central de Bun : permettre aux gens de commencer à l’utiliser immédiatement dans leurs bases de code existantes, puis de l’adopter progressivement sur davantage de parties
Et comme la plupart des nouveaux méta-frameworks comme Nuxt, SvelteKit, Astro, SolidStart ou Qwik tournent sur Vite, cela peut ouvrir une voie d’adoption pour Bun
tscPlutôt que de dire que Bun « exécute des apps TypeScript React », je dirais qu’il fournit surtout nativement la transformation JSX/TSX