Sortie de Deno 2.4

• deno bundle fait son retour, désormais basé sur esbuild, et permet de générer des bundles en fichier unique pour le serveur comme pour le navigateur, avec tree shaking et optimisation automatiques
• La prise en charge des imports de texte/octet et la stabilisation native d’OpenTelemetry renforcent l’observabilité et l’utilisation de fichiers externes
• Le nouveau flag --preload, les améliorations de confort autour des dépendances avec deno update, la mesure de couverture des scripts, la gestion des permissions et la compatibilité avec les API Node.js progressent largement
• Des améliorations pour LSP, Jupyter, bench/coverage, tsconfig ainsi que divers raffinements de confort sont également au programme

---

Principaux changements et nouvelles fonctionnalités de Deno 2.4

Retour de deno bundle

• Dans Deno 2.4, la sous-commande deno bundle, qui permet de créer un bundle JavaScript en fichier unique, est réintroduite avec le moteur esbuild
• Elle prend en charge à la fois le serveur et le navigateur, et peut aussi empaqueter sans problème des dépendances npm et JSR
• La prise en charge du tree shaking automatique et de l’optimisation du code (minify) offre un environnement plus simple à gérer
• À l’avenir, des API runtime et des plugins devraient permettre d’étendre et de personnaliser le processus de bundling par programmation

Prise en charge des imports de texte et d’octets

• Un flag --unstable-raw-imports est proposé pour permettre d’embarquer dans le graphe de modules JavaScript des fichiers de données externes comme du texte, du binaire ou des images
• Jusqu’ici, il fallait lire ces fichiers externes via des entrées/sorties (I/O), mais il est désormais possible d’utiliser directement des données texte/octet en indiquant le type de fichier dans la syntaxe d’import
• Cette fonctionnalité fonctionne aussi lors du bundling et de la compilation, ce qui facilite l’embarquement d’assets dans les livrables
• En complément de la prise en charge existante de JSON, Wasm et autres imports, elle permet de gérer plusieurs formats de fichiers de manière compatible avec les spécifications
• La discussion autour de la spécification est encore en cours, mais Deno cherche à équilibrer l’avancement fonctionnel et l’évolution des standards

Stabilisation de la prise en charge native d’OpenTelemetry

• La prise en charge native d’OpenTelemetry introduite en version 2.2 est désormais entièrement stabilisée dans la 2.4
• Il suffit de définir la variable d’environnement OTEL_DENO=1 pour automatiser la collecte de logs, métriques et traces, sans flag supplémentaire
• La compatibilité sans configuration avec Node.js ainsi que l’environnement de déploiement Deno Deploy sont pris en charge de façon unifiée
• L’association et l’observation automatiques des logs console.log et des requêtes HTTP sont également possibles
• Compte tenu de l’usage des ressources, un contrôle via variables d’environnement reste nécessaire

Flag --preload pour configurer l’environnement avant exécution

• Un flag --preload a été ajouté pour exécuter à l’avance du code destiné à modifier l’environnement global, charger des données ou enregistrer des modules de dépendance, avant l’exécution du script principal
• Il est utile dans divers cas de construction de plateforme, comme la personnalisation de la plateforme ou la réinitialisation d’objets globaux
• Il peut être utilisé avec les principales commandes comme deno run, deno test et deno bench

Gestion simplifiée des dépendances : deno update

• La sous-commande deno update est introduite pour mettre automatiquement à jour vers les dernières versions des dépendances npm et JSR
• Elle permet de mettre à jour plusieurs dépendances à la fois et prend en charge des mises à jour précises fondées sur la compatibilité Semver
• Elle est également proposée comme alias de deno outdated --update, ce qui améliore le confort d’utilisation

Couverture des scripts : deno run --coverage

• Il devient possible de collecter la couverture non seulement de chaque test, mais aussi de l’ensemble de l’exécution, y compris les subprocess
• La gestion des données reste souple grâce à différents mécanismes, dont la variable d’environnement DENO_COVERAGE_DIR
• Le rapport de couverture HTML prend désormais aussi en charge le mode sombre

Variable d’environnement de compatibilité Deno DENO_COMPAT=1

• La variable DENO_COMPAT=1 est introduite pour améliorer la commodité et la compatibilité avec l’écosystème npm et les projets basés sur package.json
• Elle applique automatiquement plusieurs flags instables (Unstable), et son périmètre devrait encore s’élargir à l’avenir, par exemple avec la suppression du préfixe npm

Améliorations de la gestion des permissions et de la sécurité

• Le flag --allow-net prend désormais en charge les wildcards de sous-domaines et les plages CIDR
• De nouveaux flags --allow-import, pour restreindre les hôtes depuis lesquels le code peut importer, et --deny-import, pour les bloquer explicitement, font leur apparition
• L’API Deno.permissions prend officiellement en charge les requêtes de type "import"
• L’utilisation de Deno.execPath() ne nécessite plus de permission de lecture, ce qui facilite l’exploitation du chemin de l’exécutable

Exports conditionnels dans package.json

• Les exports conditionnels des packages npm sont pris en charge, ce qui renforce notamment la compatibilité avec divers écosystèmes comme les configurations serveur de React
• Des flags de conditions utilisateur permettent de mettre en place un comportement d’import personnalisé et flexible

Prise en charge des bare specifiers dans deno run

• Il est désormais possible d’exécuter un point d’entrée de commande à partir d’un alias (bare specifier) défini dans "imports" de deno.json
• Cela apporte un vrai gain de confort pour la productivité et l’automatisation de la gestion des modules

Amélioration du formatage du code pour XML, SVG et autres formats

• deno fmt prend désormais en charge le formatage automatique de divers fichiers de templates comme .xml, .svg et .mustache

Renforcement de la prise en charge de tsconfig.json

• La précision de reconnaissance de nombreuses options comme references, extends, files, include et exclude a été améliorée
• Une meilleure compatibilité est proposée avec des frameworks frontend modernes comme Vue, Svelte, Solid et Qwik

Compatibilité accrue avec les variables globales et API Node

• Les objets globaux Node.js comme Buffer, global, setImmediate et clearImmediate sont désormais toujours disponibles dans le code utilisateur
• Des globales auparavant réservées aux packages npm peuvent aussi être utilisées directement, sans flag de commande
• Avec node:buffer, node:events, node:querystring, node:quic, node:wasm et d’autres, Deno atteint une compatibilité de plus de 95 %, qui continuera de progresser
• La version de base des types @types/node a aussi été mise à jour en 22.15.14

Changement dans la gestion des packages npm locaux

• Le nom de l’option de liaison des packages npm locaux passe de patch à links, en cohérence avec le sens de npm link
• L’utilisation de l’ancienne option affiche un avertissement de dépréciation, pour une gestion des packages plus claire

Améliorations du LSP et de la productivité de développement

• En plus des améliorations de performances et de fonctionnalités du LSP, diverses commodités sont proposées, comme la prise en charge des sockets Unix/Vsock par fetch, le callback onListen du serveur, la gestion du noyau Jupyter, la lecture des commentaires dans les plugins de lint, ainsi que la compatibilité Markdown des tableaux bench/coverage
• Sous Windows, la reconnaissance du signal Ctrl+Close (windows SIGHUP) ainsi que le format Markdown de la sortie texte de bench/coverage ont également été améliorés

Remerciements à la communauté et aux contributeurs

• Le développement de Deno 2.4 a largement bénéficié de la participation et des retours de nombreux contributeurs de la communauté
• Pour plus d’informations et le détail des changements, voir la page GitHub des releases

Conclusion

• Deno 2.4 apporte des avancées majeures sur de nombreux plans : bundling, import de fichiers externes, observabilité, permissions/sécurité, compatibilité et productivité
• Il permet une expérience de développement intégrée simple et puissante pour les flux de travail modernes, les frontends récents et les projets de l’écosystème Node
• Des informations supplémentaires, les dernières actualités et l’historique complet des changements sont disponibles dans la documentation officielle, le blog et la page GitHub des releases

[GN⁺]

Avis Hacker News

• J’aime vraiment le concept de Deno, donc j’ai essayé d’appliquer au maximum Deno.json, JSR, les imports modernes, Deno Deploy, etc. dans un projet monorepo avec Next.js, Hono et des packages privés. Hono fonctionnait proprement, mais pas Next.js, et j’ai aussi eu quelques soucis subtils avec les types. Le choix de la cible de déploiement (Vercel, etc.) posait aussi problème de mémoire. Je partage un petit souci rencontré en exemple via un lien d’issue. À l’inverse, Bun, même s’il n’était pas aussi élégant à l’usage que Deno, demandait moins de réflexion et donnait l’impression que ça « fonctionne », tout simplement. Cela dit, Bun n’est pas parfait non plus, par exemple avec l’absence de support du runtime Bun sur Vercel

  • Conseil reçu : le stack choisi restait encore très centré sur npm, surtout dans un environnement avec beaucoup de packages npm privés, donc c’était un peu trop ambitieux. À mon avis, le vrai point fort de l’approche Deno apparaît quand on choisit un stack nativement Deno ou compatible ESM. J’ai eu une bonne expérience avec Lume ou en ciblant Deno Deploy. (Le score JSR aide aussi à découvrir des bibliothèques intéressantes et très compatibles ESM.) Bien sûr, repartir sur un stack entièrement neuf est difficile en pratique, et l’investissement existant dans Next.js, etc. est important, donc recommander Deno reste délicat. Mais selon moi, les avantages de Deno ressortent vraiment quand on repart de zéro avec tout un ensemble d’outils Deno-native et ESM-native. À noter que la compatibilité npm de Deno s’améliore progressivement, et les notes de version 2.4 contiennent aussi des améliorations en ce sens. En environnement full-stack, privilégier package.json plutôt que deno.json offre paradoxalement une meilleure compatibilité, donc à long terme, même si pousser deno.json a du sens, je recommande aussi une configuration basée sur package.json

  • En essayant Deno en mode de compatibilité npm, j’ai trouvé que ça marchait étonnamment bien. C’est très proche de la manière d’utiliser Bun. Si on lance deno install dans un répertoire contenant un package.json, cela crée un node_modules allégé, et la commande deno task something permet d’exécuter les scripts définis dans package.json. En revanche, la façon propre à Deno prend souvent plus de temps et devient frustrante, et quand on veut revenir à un environnement node/npm, cela complique encore les choses. En conclusion, utiliser Deno avec package.json est plus simple

  • Au début, j’étais parti à fond sur Deno, mais il y avait trop de petits problèmes pénibles. À côté de ça, Bun fonctionne bien sans qu’on ait grand-chose à gérer

• Les gens ont tendance à sous-estimer la compatibilité node de Deno. J’espère que l’adoption de la variable d’environnement compat aidera à sa diffusion. Ce serait encore plus pratique si des commandes comme denon l’activaient automatiquement

  • D’après mon expérience, la compatibilité node de Deno était en dessous des attentes, ce qui m’a déçu. Il m’a fallu environ une heure pour migrer un petit projet de 100 à 200 lignes vers Deno, alors qu’en réalité cela aurait dû prendre 5 à 10 minutes. Certaines méthodes de node n’étaient pas prises en charge, la documentation associée était insuffisante, et même des fonctionnalités de base devaient être téléchargées directement depuis des URL obscures. Lors du portage de la suite de tests, j’ai fini par abandonner. En particulier, la transition de CommonJS (CJS) vers ESM a été bien plus douloureuse que prévu, et certainement pas aussi simple que ce que laisse entendre la documentation officielle de Deno. Je n’ai finalement pas pu porter toute la bibliothèque

  • J’étais plutôt positif sur Deno auparavant, mais maintenant je ne vois pas vraiment de raison de l’utiliser à la place de Bun

• La liste des changements récents de Deno est jugée bonne. Je l’utilise avec satisfaction pour écrire des scripts aléatoires ou du glue code (pour le machine learning, etc., j’utilise plutôt python/uv), et j’attends avec intérêt le support futur de gRPC ainsi que la commande de bundling

• Certains trouvent étonnant que Deno ne fonctionne toujours pas correctement sur FreeBSD. Les bindings V8 en Rust n’y ont pas encore été portés

  • Je me demande combien de développeurs JavaScript modernes utilisent réellement FreeBSD

  • Avant, la portabilité entre Unix était un indicateur de propreté du code, mais aujourd’hui je suis surpris de voir à quel point la compatibilité entre différents systèmes Unix est peu mise en avant

  • Il semble pourtant être enregistré dans les ports FreeBSD

  • Il est tout à fait compréhensible qu’ils ne consacrent pas beaucoup d’efforts au support de FreeBSD

• Selon un avis, si Deno n’est pas davantage utilisé en production, c’est à cause de l’absence d’une base de données de vulnérabilités standardisée. La compatibilité npm à 100 % peut compenser cela, mais dans ce cas la plupart des packages deno populaires sortent du périmètre. Fondamentalement, l’absence de gestionnaire de paquets centralisé (par choix de conception) est un défi. Question posée : y a-t-il eu des avancées sur ce point ?

  • Réponse : si l’absence de base de données de vulnérabilités est réellement un gros problème en production, alors on ne pourrait pas non plus utiliser C/C++. En pratique, pour C/C++, on s’appuie sur des bases comme CVE/GHSA, neutres vis-à-vis des langages, pour suivre les problèmes de sécurité. D’ailleurs, en C, il est fréquent de simplement vendoriser des fichiers externes sans même faire de suivi de version. Il existe aussi un fichier deno.lock, donc ceux qui y prêtent attention peuvent s’en servir pour vérifier les vulnérabilités des versions effectivement utilisées

  • Le fait de récupérer directement les packages depuis des URL (GitHub, etc.) ressemble aussi à Go, donc le même problème s’y applique également

• Le retour de la sous-commande bundle plaît beaucoup. Plus besoin de solutions de contournement pénibles, c’est appréciable

• Le choix d’esbuild plutôt que de Rolldown, basé sur Rust, pour le bundling a surpris. Rolldown devrait bientôt passer en v1

  • esbuild est aujourd’hui très stable et mature, tandis que Rolldown évolue encore rapidement, donc choisir esbuild est plus raisonnable

• J’aime vraiment la direction prise par Deno, et j’ai l’impression que Node aurait dû être comme ça dès le départ. Ma crainte, en revanche, c’est que Deno se laisse lui aussi entraîner sans recul par la « hype » de ses concurrents

  • On peut aussi dire que Deno lui-même a longtemps été perçu comme un concurrent de Node.js porté par la « hype »

• Je continue à entendre de bonnes choses sur Deno. Du coup, je commence à me dire que je devrais peut-être essayer js

  • De nos jours, partir directement sur TS peut aussi être un bon choix

• D’un point de vue sécurité, je soutiens Deno, mais j’ai déjà été gêné de voir le site officiel recommander aux utilisateurs une installation du type curl mywebsite.com/foo.sh | sh. Bien sûr, chacun a son propre niveau de tolérance au risque, mais au minimum, si l’on télécharge d’abord le fichier avant de l’exécuter, soi-même ou son antivirus peut l’inspecter. L’écosystème Node/Deno + npm repose de toute façon sur un niveau de confiance assez élevé. Le guide officiel propose aussi l’option npm install -g deno en plus de curl | sh, et npm offre au moins une vérification minimale de l’intégrité des fichiers ainsi qu’un contrôle simple contre les malwares, ce qui paraît relativement plus sûr. Le site deno.land peut être sûr au niveau du codebase, sans que cela garantisse à 100 % la sécurité opérationnelle, donc à mes yeux curl | sh n’est pas une bonne pratique de sécurité

  • Je ne suis pas d’accord avec cette logique. La plupart des scripts d’installation ne font au final que télécharger puis exécuter un binaire de quelques centaines à plusieurs millions de lignes écrit par le même auteur. Si on ne fait tellement pas confiance à l’auteur qu’on imagine son serveur capable d’envoyer un malware seulement à certaines IP, alors il pourrait tout aussi bien injecter un malware directement au niveau du binaire, et dans ce cas il ne faudrait tout simplement pas utiliser ce projet. Si le débat sur curl | sh est si répandu, c’est probablement parce que c’est un argument simple et facile à répéter ; le vrai sujet de sécurité, c’est plutôt la revue de centaines de milliers ou millions de lignes de code. Si l’on s’inquiète jusqu’aux attaques MITM d’organismes gouvernementaux, il ne reste qu’à couper toute confiance vis-à-vis d’Internet

  • On souligne aussi la difficulté de l’onboarding des nouveaux utilisateurs. Même si l’on recommande d’utiliser npm, il faut déjà avoir npm installé ; or le site officiel de npm explique comment installer nvm, et nvm lui-même utilise curl | sh. Au final, la voie npm retombe indirectement sur le même problème

  • Dans la discussion sur le fait de savoir si npm install -g deno est réellement plus sûr que curl | sh, le point clé est : lequel est le plus facile à compromettre pour un attaquant, les serveurs npm ou les serveurs du projet lui-même ? Si l’on peut être certain qu’il n’y a pas eu de compromission du serveur du projet, alors curl | sh n’a pas de raison d’être moins sûr que npm install. Au bout du compte, du point de vue de la sécurité, ces deux méthodes peuvent être vulnérables de manière équivalente ; poussé à l’extrême, le vrai problème serait simplement d’utiliser Internet

  • Critique selon laquelle l’implémentation de la sandbox de Deno donne l’impression d’une technologie des années 90, et que son utilisation n’encourage pas vraiment de bonnes pratiques de sécurité

  • Quelqu’un demande s’il existe des cas réels où une attaque via l’installation curl | sh a effectivement réussi