Deno 2.8

• deno add et deno install traitent désormais par défaut les noms de paquets sans préfixe comme des paquets npm:, ce qui les rend plus faciles à utiliser à la place de npm install, yarn ou pnpm install dans les projets Node existants
• deno audit fix met automatiquement à niveau les paquets npm vulnérables vers la version patch la plus proche qui respecte les contraintes de version, et affiche séparément les éléments nécessitant un changement de version majeure
• De nouvelles sous-commandes, deno ci, deno pack, deno transpile, deno why, deno bump-version, ont été ajoutées pour prendre en charge les installations reproductibles, la création de tarballs pour la publication npm, la conversion TS→JS, le suivi des chemins de dépendance et la mise à jour des versions de workspace
• La compatibilité avec l’API Node.js est passée d’environ 42 % dans Deno 2.7 à 76,4 % (3 405/4 457) dans Deno 2.8 selon la propre suite de tests de Node, et de nombreux modules node: sont désormais chargés de façon différée, ce qui accélère le démarrage des programmes qui ne les utilisent pas
• Côté performances, par rapport à Deno 2.7.1, une installation npm à froid est passée de 3 319 ms à 906 ms, soit 3,66 fois plus rapide, tandis que node:buffer base64 s’améliore de 3,07 fois, le débit de node:http de 2,21 fois et node:crypto scrypt de 2,12 fois
• Parmi les changements de compatibilité, les fonctions globales setTimeout et setInterval renvoient désormais l’objet Timeout de Node au lieu d’un nombre ; le code qui stockait la valeur de retour comme number ou l’utilisait dans des vérifications de type ou des opérations arithmétiques doit être adapté, par exemple avec NodeJS.Timeout
• TypeScript 6.0.3 est intégré, et deno check ainsi que le LSP incluent désormais lib.node par défaut, ce qui permet de résoudre des types Node comme NodeJS.*, Buffer et process sans configuration supplémentaire
• Côté débogage, l’onglet Network de Chrome DevTools affiche le trafic fetch() de Deno, node:http/node:https et WebSocket, tandis que --cpu-prof, --cpu-prof-flamegraph et --cpu-prof-md permettent de générer un profil V8, un flamegraph SVG et un rapport Markdown
• Pour la gestion des paquets et des workspaces, le protocole catalog:, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", min-release-age dans .npmrc et --package-json ont été ajoutés pour faciliter l’unification des versions en monorepo, les installations cross-platform, les installations de production et la migration depuis des projets Node existants
• deno compile détecte les projets Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start et Vite SSR, exécute deno task build et génère le point d’entrée approprié, tout en affichant aussi la progression lors du traitement de grands arbres de dépendances npm
• Pour les tests et les Web API, les valeurs par défaut de sanitizeOps et sanitizeResources dans Deno.test() passent à false, un timeout par test et une couverture au niveau des fonctions sont ajoutés, et la prise en charge de OffscreenCanvas, des Headers, Request, Response et Streams transférables, du digest SHA3 et de Web Crypto P-521 est introduite
• Côté mise à niveau et fondation du runtime, deno upgrade réduit les téléchargements d’environ 48 Mo à 3–6 Mo grâce aux mises à jour delta lorsque c’est possible, permet d’installer des builds de PR avec deno upgrade pr <number>, et V8 passe de 14.6 à 14.9

[GN⁺]

Avis sur Hacker News

• Deno est utile grâce à son modèle d’autorisations par défaut, il est écrit en Rust et prend en charge TypeScript nativement
  Je ne suis pas très plongé dans l’écosystème web dev/Node/Bun, mais j’utilise Deno avec satisfaction sur de petits services depuis quelques années. Je me demande pourquoi Bun semble croître si vite. Je ne sais pas s’il est surtout utilisé comme bundler et moins comme runtime JavaScript
  Rien que le système d’autorisations rend Deno attractif, et j’ai du mal à comprendre pourquoi, en quittant Node pour Bun, on ne va pas plutôt vers Deno

  • Deno et Bun avaient des priorités assez différentes à leur lancement. Deno, avec Ryan, le créateur originel de Node, cherchait à corriger beaucoup de choses qu’il jugeait ratées dans Node, tandis que Bun s’est concentré dès le départ sur la compatibilité Node et l’exécution de frameworks populaires comme Next.js
    Pendant longtemps, beaucoup de dépendances et de frameworks ne fonctionnaient pas correctement sur Deno, et au début il n’y avait même pas de moyen d’installer des dépendances depuis npm. Quand on repense aux attaques sur la supply chain npm, Ryan avait peut-être raison
    Bun ressemblait donc à un meilleur Node, avec beaucoup de fonctions pratiques, bien moins de configuration et quelque chose qui fonctionne immédiatement. L’équipe Deno semble avoir compris qu’il fallait la compatibilité Node pour réussir et s’y est concentrée ces dernières années. À ce stade, je considère Deno comme plus compatible avec Node que Bun
  • Quand on démarre un petit side project TypeScript, on peut juste utiliser Bun au lieu de se noyer dans l’océan npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime
    À titre indicatif, seuls certains de ces noms sont des capacités Pokémon, les autres sont de vrais outils de l’écosystème JS/TS
  • J’utilise les deux et je les apprécie. Bun est plus proche d’un remplaçant direct de Node
    Quand je n’ai pas envie de toucher à la configuration des tests, à tsconfig ou aux modules ES, ça marche simplement. Deno a une bonne bibliothèque standard et un excellent support CLI, et j’aimais aussi deno deploy auparavant, mais c’est devenu assez pénible ces derniers temps
  • Je fais surtout du backend, mais quand je touche un peu au frontend sur des projets personnels, Deno semble être le choix le plus raisonnable
    C’est vraiment agréable à utiliser, et c’est dommage qu’il ne se soit pas davantage diffusé chez les gens du JS
  • J’ai utilisé Deno pendant environ un an et je l’aimais pour les avantages mentionnés plus haut, mais il y avait trop de problèmes de compatibilité avec des packages comme Astro, Prisma et Vite
    Je suis donc passé à Bun, et l’expérience a été bien plus fluide

• Je me demande dans quel état est Deno aujourd’hui
  Node est la solution stable et restera là dans le futur. On peut maintenant y utiliser TypeScript, et il semble qu’on pourra bientôt construire une application en fichier exécutable unique, y compris avec des dépendances natives
  Bun est confus mais rapide, et son approche consistant à tout inclure dans la bibliothèque standard est intéressante. En plus, il a été acquis par Anthropic
  Deno avait une histoire séduisante avec son sandboxing et la facilité d’importer des dépendances tierces, mais le sandboxing semble maintenant assez généralisé, et je ne suis pas certain que cette façon d’importer ait finalement été tellement meilleure que npm add

  • Deno a licencié environ la moitié de son entreprise il y a à peu près 2 mois : https://news.ycombinator.com/item?id=47467746
  • Qui voit positivement un rachat par Anthropic ?
  • Il est bon d’avoir plusieurs options pour éviter que l’écosystème ne stagne
  • Le déploiement en fichier exécutable unique est déjà possible. Le CLI de mon produit est une application Node en fichier exécutable unique
  • Je ne savais pas qu’on allait pouvoir construire un fichier exécutable unique avec des dépendances natives incluses. C’est une fonctionnalité puissante

• Deno est excellent. J’écris de petits et moyens services web avec Deno
  Ça tourne comme une horloge suisse, et la philosophie du projet s’accorde bien avec l’esprit Unix
  Personnellement, je trouve que les créateurs de Deno sont un peu trop modestes. Même quand des utilisateurs reconnaissants proposent de faire un don au projet, ils refusent poliment. Je comprends pourquoi, mais cela peut aussi créer à long terme une pression financière inutile sur le projet
  Un abonnement mensuel du type « s’il vous plaît, prenez notre argent » pourrait assez bien convenir aux utilisateurs qui dépendent du succès à long terme du projet

  • C’est vraiment un plaisir à utiliser. On a presque l’impression d’un mélange entre JavaScript et Go
    C’est rapide, flexible, avec une gestion de paquets un peu plus saine et plus puissante que les autres alternatives JS/TS, un meilleur modèle de sécurité, une meilleure bibliothèque standard. Et c’est très rapide

• Pour ceux à qui le nom Deno n’est pas familier, Deno est un runtime JavaScript et TypeScript
  Il existe un test comparatif de Deno 2.6 face à ses concurrents Bun 1.3 et Node.js 25 : https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Il est surprenant que Bun soit tellement plus rapide pour traiter les requêtes web. L’article l’attribue à Zig, mais je me demande si une gestion fine de la mémoire suffit vraiment à obtenir un gain de plus du double par rapport à Node
    De même, sans que ce soit dit explicitement, Bun semble avoir été exécuté avec un cache de packages déjà chaud. Je me demande si les autres runtimes avaient eux aussi un cache

• Le rythme de publication régulier de Deno est impressionnant. J’ai hâte de voir quelles améliorations de performances cette version apporte

• La nouvelle commande deno pack est un bon ajout pour un packaging simple et sûr
  Si vous utilisez Node.js, on peut faire quelque chose de similaire avec une commande unique via https://www.npmjs.com/package/ts-node-pack
  Maintenant que Node.js prend en charge l’import de modules .ts, davantage de dépôts pourront l’utiliser sans étape de build ni ajout des artefacts de build dans le checkout

  • En lisant ce billet de blog, je me suis immédiatement posé la question. deno pack pourrait remplacer le flux existant npm publish de mon package open source, et m’aider à poursuivre le déplacement de mon travail vers une approche Deno-first / centrée sur Deno
    À l’inverse, comme le support TypeScript progresse dans Node, passer à un package npm uniquement TypeScript pourrait aussi être un très petit message envoyé à l’écosystème
    Cela dit, je suis content que JSR existe comme écosystème relativement plus propre
  • Ça ressemble beaucoup à DNT qui existe depuis longtemps (https://github.com/denoland/dnt)
    Mais le fait d’être intégré à la CLI Deno lui donne beaucoup plus de visibilité

• Si Deno avait conservé un peu plus longtemps sa proposition de valeur initiale, la pression pour la compatibilité Node aurait peut-être été en partie comblée par les agents IA
  Une grande part de cette pression vient d’un problème de familiarité. Si on sait tout configurer uniquement avec express.js, on finit par attendre de tout outil ou runtime ultérieur qu’il fournisse des abstractions similaires pour que la transition soit « fluide ». Et ce, indépendamment du fait que la première solution ait été mauvaise à la base
  Aujourd’hui, on peut présenter de nouvelles technologies aux développeurs en livrant avec le produit l’ensemble technique nécessaire, et cela remplace parfois réellement la documentation tout en montrant assez bien une meilleure approche alternative

  • Si le SDK JS/TS fourni par une entreprise SaaS ne fonctionne pas dans Deno sans modifications, je n’y consacrerai pas une seconde pour corriger ça

• Pour avoir utilisé Deno sur plusieurs projets de loisir, je suis convaincu que Deno est la direction que l’écosystème JS devrait prendre
  En revanche, c’est compliqué de le recommander au travail en dehors de cas d’usage précis et généralement limités. À un moment donné, si le projet change de direction pour des raisons business, on finit par avoir besoin de Node

• Depuis la sortie d’Edge.js [1], c’est bien de voir Deno prendre la compatibilité Node.js plus au sérieux
  En environ 2 mois, on est passé d’un peu plus de 40 % à environ 75 %, donc coïncidence ou non, c’est clairement un pas dans la bonne direction
  Bravo à toute l’équipe Deno
  [1] https://edgejs.org/

  • Tu ne te lasses pas de l’auto-promo ?

• J’utilise Deno comme runtime en enveloppant la plupart des idiomes à la Node. Ça fonctionne bien
  Si un projet est en pur TypeScript, je l’exécute simplement avec Deno. J’apprécie aussi les options supplémentaires pour la sécurité et le fait que les scripts d’installation soient désactivés par défaut
  Si vous utilisez encore Node directement, vous devriez arrêter. À tout le moins, Bun me semble préférable
  Pour le travail avec des agents, il n’y a presque aucune raison d’utiliser autre chose que Rust et TypeScript. On peut ne pas être d’accord, mais la sûreté de typage, la sûreté mémoire et l’énorme corpus de travail comptent. Les agents explorent plus facilement quand il y a des erreurs pointilleuses et des patterns intégrés. Pour l’UI, TypeScript est le plus pertinent vu la masse d’exemples de design disponibles