Deno 2.4 veröffentlicht

• deno bundle wurde auf esbuild-Basis wieder eingeführt und kann nun Single-File-Bundles für Server und Browser erzeugen, inklusive automatischem Tree Shaking und Optimierung
• Unterstützung für Text-/Byte-Imports sowie die integrierte Stabilisierung von OpenTelemetry verbessern Observability und die Nutzung externer Dateien
• Das neue Flag --preload, die komfortablere Abhängigkeitsverwaltung mit deno update, Skript-Coverage, Berechtigungsverwaltung und die Node.js-API-Kompatibilität wurden umfassend verbessert
• Verbesserungen bei LSP, Jupyter, bench/coverage, tsconfig sowie verschiedene Komfortverbesserungen sind ebenfalls enthalten

---

Zusammenfassung der wichtigsten Änderungen und neuen Funktionen in Deno 2.4

Die Rückkehr von deno bundle

• In Deno 2.4 wurde der Subbefehl deno bundle zur Erstellung von JavaScript-Bundles in einer einzigen Datei zusammen mit der esbuild-Engine wieder aufgenommen
• Er unterstützt sowohl Server als auch Browser, und auch npm- und JSR-Abhängigkeiten lassen sich problemlos bundlen
• Mit Unterstützung für automatisches Tree Shaking und Code-Optimierung (Minify) wird die Verwaltung deutlich komfortabler
• Künftig sollen über Runtime-APIs und Plugins zusätzliche programmatische Erweiterungen und Anpassungen des Bundle-Prozesses möglich werden

Unterstützung für Text- und Byte-Imports

• Mit dem Flag --unstable-raw-imports können externe Datendateien wie Text, Binärdateien oder Bilder in den JavaScript-Modulgraphen eingebettet werden
• Bisher mussten solche Dateien per Datei-Ein-/Ausgabe (I/O) gelesen werden, jetzt können über Import-Syntax mit Dateityp Byte- und Textdaten direkt verwendet werden
• Die Funktion arbeitet auch beim Bundling und Kompilieren, sodass sich Asset-Einbettung im Ergebnis einfach umsetzen lässt
• Zusammen mit der bestehenden Import-Unterstützung für JSON, Wasm usw. können verschiedene Dateiformate spezifikationsfreundlich verwaltet werden
• Die Spezifikation ist noch in Diskussion, aber Deno berücksichtigt ausgewogen sowohl funktionale Weiterentwicklung als auch Standardisierungstrends

Integrierte OpenTelemetry-Unterstützung jetzt stabil

• Die in Version 2.2 eingeführte eingebaute OpenTelemetry-Unterstützung ist in 2.4 vollständig stabilisiert
• Wenn nur die Umgebungsvariable OTEL_DENO=1 gesetzt wird, können Logs, Metriken und Traces ohne zusätzliche Flags automatisch erfasst werden
• Konfigurationslose Kompatibilität mit Node.js sowie Unterstützung für Deno-Deploy-Umgebungen werden einheitlich bereitgestellt
• Auch die automatische Verknüpfung und Beobachtung von console.log-Ausgaben und HTTP-Anfragen ist möglich
• Aufgrund der Ressourcennutzung ist eine Steuerung über Umgebungsvariablen erforderlich

Das Flag --preload für Umgebungsvorbereitung vor der Ausführung

• Das Flag --preload wurde hinzugefügt, um vor der Ausführung des Hauptskripts Code vorab laufen zu lassen, etwa für Änderungen an der globalen Umgebung, das Laden von Daten oder die Registrierung abhängiger Module
• Das ist nützlich für verschiedene Formen des Plattform-Setups, etwa Plattform-Anpassungen oder das Zurücksetzen globaler Objekte
• Es kann in zentralen Kommandos wie deno run, deno test und deno bench verwendet werden

Vereinfachte Abhängigkeitsverwaltung: deno update

• Der Subbefehl deno update wurde eingeführt, um npm- und JSR-Abhängigkeiten automatisch auf die neuesten Versionen zu aktualisieren
• Unterstützt das gleichzeitige Aktualisieren mehrerer Abhängigkeiten sowie präzise Updates auf Basis der Semver-Kompatibilität
• Wird auch als Alias für deno outdated --update bereitgestellt und verbessert damit den Nutzungskomfort

Skript-Coverage: deno run --coverage

• Nicht nur einzelne Tests, sondern die gesamte Ausführung inklusive Subprozessen kann nun für Coverage erfasst werden
• Flexible Datenverwaltung ist über verschiedene Wege möglich, darunter die Umgebungsvariable DENO_COVERAGE_DIR
• HTML-Coverage-Reports unterstützen jetzt auch den Dark Mode

Deno-Kompatibilitätsvariable DENO_COMPAT=1

• Die Variable DENO_COMPAT=1 wurde eingeführt, um Benutzerfreundlichkeit und Kompatibilität im npm-Ökosystem und bei package.json-basierten Projekten zu verbessern
• Sie aktiviert automatisch mehrere instabile (Unstable) Flags; künftig soll der Umfang weiter ausgebaut werden, etwa durch Weglassen des npm-Prefixes

Verbesserungen bei Berechtigungen und Sicherheit

• Das Flag --allow-net unterstützt nun Subdomain-Wildcards und CIDR-Bereiche
• Neu hinzugekommen sind die Flags --allow-import zum Einschränken erlaubter Import-Hosts und --deny-import zum expliziten Blockieren
• Die Deno.permissions-API unterstützt nun offiziell Abfragen des Typs "import"
• Für die Nutzung von Deno.execPath() ist keine Leseberechtigung mehr erforderlich, wodurch sich der Pfad zur ausführbaren Datei leichter verwenden lässt

Bedingte package.json-Exports

• Unterstützung für bedingte Exports in npm-Paketen stärkt die Kompatibilität mit verschiedenen Ökosystemen, insbesondere mit React-Server-Konfigurationen
• Über benutzerdefinierte Bedingungs-Flags lässt sich das Importverhalten flexibel anpassen

Unterstützung für Bare Specifier in deno run

• Einstiegspunkte lassen sich nun mit Aliasen (Bare Specifiers) aus "imports" in deno.json ausführen
• Das bringt deutliche Vorteile für Entwicklerproduktivität und automatisierte Modulverwaltung

Verbesserte Code-Formatierung für XML, SVG und weitere Formate

• deno fmt unterstützt nun die automatische Formatierung verschiedener Template-Dateien wie .xml, .svg und .mustache

Erweiterte Unterstützung für tsconfig.json

• Die Erkennung verschiedener Optionen wie references, extends, files, include und exclude wurde verbessert
• Dadurch steigt die Kompatibilität mit modernen Frontend-Frameworks wie Vue, Svelte, Solid und Qwik

Mehr Kompatibilität bei Node-Globals und APIs

• Node.js-Globale Objekte wie Buffer, global, setImmediate und clearImmediate sind nun auch im Benutzercode immer vorhanden
• Auch bisher npm-paketspezifische Globals können ohne Kommando-Flags direkt verwendet werden
• Für node:buffer, node:events, node:querystring, node:quic, node:wasm und weitere liegt die Kompatibilität nun bei über 95 % und soll weiter ausgebaut werden
• Die Standardversion der @types/node-Typen wurde ebenfalls auf 22.15.14 aktualisiert

Änderungen bei lokalen npm-Paketen

• Der Name der Option zum Verknüpfen lokaler npm-Pakete wurde von patch zu links geändert und entspricht damit besser der Bedeutung von npm link
• Bei Verwendung der bisherigen Option wird eine Deprecation-Warnung ausgegeben, was für klarere Paketverwaltung sorgt

Verbesserungen bei LSP und Entwicklerproduktivität

• Neben Leistungs- und Funktionsverbesserungen im LSP gibt es viele weitere Komfortfunktionen: Unix-/Vsock-Socket-Unterstützung für fetch, den onListen-Callback des Servers, Jupyter-Kernel-Verwaltung, das Lesen von Kommentaren in Lint-Plugins und Markdown-Kompatibilität für bench-/coverage-Tabellen
• Auch die Erkennung des Ctrl+Close-Signals unter Windows (Windows SIGHUP) sowie Markdown-Formatierung für die Textausgabe von bench/coverage wurden verbessert

Dank an Community und Mitwirkende

• Die Weiterentwicklung von Deno 2.4 wurde maßgeblich durch die Beteiligung und das Feedback zahlreicher Community-Mitwirkender geprägt
• Weitere Inhalte und detaillierte Änderungen finden sich auf der GitHub-Release-Seite

Fazit

• Deno 2.4 bringt große Fortschritte in vielen Bereichen, darunter Bundling, Import externer Dateien, Observability, Berechtigungen/Sicherheit, Kompatibilität und Produktivität
• In modernen Entwicklungsabläufen sowie in aktuellen Frontend- und Node-Ökosystem-Projekten ermöglicht es eine einfache und leistungsfähige integrierte Entwicklungsumgebung
• Weitere Informationen, aktuelle Neuigkeiten und das vollständige Änderungsprotokoll sind in der offiziellen Dokumentation, im Blog und auf der GitHub-Release-Seite verfügbar

[GN⁺]

Hacker-News-Kommentare

• Mir gefällt das Konzept von Deno wirklich sehr, deshalb habe ich versucht, es in einem Monorepo-Projekt mit Next.js, Hono und privaten Paketen so weit wie möglich einzusetzen — inklusive Deno.json, JSR, moderner Imports und Deno Deploy. Hono funktionierte sauber, Next.js dagegen nicht, und auch bei Typen gab es Fälle, in denen subtil etwas kaputtging. Auch die Wahl des Deployment-Ziels (z. B. Vercel) war problematisch. Als Beispiel für ein kleines Problem, das ich erlebt habe, teile ich diesen Issue-Link. Bun wirkte dagegen zwar nicht so sauber wie Deno, aber man musste über weniger nachdenken und es hatte den Eindruck, einfach zu „funktionieren“. Perfekt ist Bun aber auch nicht, etwa weil die Bun-Runtime auf Vercel nicht unterstützt wird

  • Der Hinweis dazu war, dass der gewählte Stack weiterhin stark npm-zentriert war — besonders in Umgebungen mit vielen privaten npm-Paketen war das wohl zu ambitioniert. Die eigentliche Stärke des Deno-Ansatzes liegt meiner Meinung nach darin, von Haus aus einen Deno- oder ESM-freundlichen Stack zu wählen. Die Erfahrungen mit Lume oder einem auf Deno Deploy ausgerichteten Setup waren gut. (Der JSR-Score hilft außerdem dabei, interessante Bibliotheken mit starker ESM-Kompatibilität zu entdecken.) Natürlich ist es in der Praxis schwer, einfach mit einem komplett neuen Stack zu beginnen, und in bestehende Investitionen wie Next.js ist oft schon viel geflossen, deshalb fällt eine Empfehlung für Deno schwer. Aber seine Vorteile zeigen sich meiner Ansicht nach dann am deutlichsten, wenn man von Grund auf in einer Deno-native- und ESM-native-Toolchain startet. Immerhin wird Denos npm-Kompatibilität stetig besser, und auch in den Release Notes zu 2.4 gibt es dazu Verbesserungen. In Full-Stack-Umgebungen ist ein Ansatz mit package.json statt deno.json derzeit eher kompatibler, daher würde ich langfristig zwar weiter in Richtung deno.json gehen, aber Setups auf Basis von package.json ebenfalls empfehlen

  • Ich habe Deno im npm-Kompatibilitätsmodus ausprobiert und war überrascht, wie gut es funktioniert. Das ähnelt stark der Art, wie man Bun nutzt. Führt man deno install in einem Verzeichnis mit package.json aus, erstellt es ein schlankes node_modules, und mit dem Befehl deno task something lassen sich in package.json definierte Skripte ausführen. Der Deno-spezifische Weg kostet aber oft viel Zeit und war deshalb frustrierend, und wenn man danach wieder in eine node/npm-Umgebung zurückwill, wird es nur noch komplizierter. Mein Fazit: Deno zusammen mit package.json zu nutzen, ist der einfachere Weg

  • Ich war anfangs voll auf Deno eingeschossen, aber die vielen kleinen Probleme waren einfach zu mühsam. Im Vergleich dazu funktioniert Bun ohne großes Nachdenken einfach gut

• Die Node-Kompatibilität von Deno wird meiner Meinung nach von vielen unterschätzt. Ich hoffe, dass die Einführung einer compat-Umgebungsvariable die Verbreitung fördern wird. Noch praktischer wäre es, wenn Befehle wie denon das automatisch aktivieren würden

  • Nach meiner Erfahrung blieb Denos Node-Kompatibilität hinter den Erwartungen zurück. Ich habe etwa eine Stunde gebraucht, um ein einfaches Projekt mit 100–200 Zeilen auf Deno umzustellen, obwohl das eigentlich in 5–10 Minuten erledigt sein sollte. Manche Methoden aus Node wurden nicht unterstützt, die dazugehörige Dokumentation war dürftig, und selbst grundlegende Funktionen musste man direkt von obskuren URLs herunterladen. Beim Portieren der Test-Suite habe ich am Ende aufgegeben. Vor allem der Wechsel von CommonJS (CJS) zu ESM war deutlich schmerzhafter als erwartet und keineswegs so einfach, wie es die Deno-Dokumentation darstellt. Ich habe erlebt, dass sich eine komplette Bibliothek nicht portieren ließ

  • Früher war ich Deno gegenüber ziemlich positiv eingestellt, aber inzwischen sehe ich keinen besonderen Grund mehr, statt Bun Deno zu verwenden

• Die Liste der jüngsten Änderungen an Deno wird gelobt. Ich nutze Deno zufrieden für zufällige Skripte und Glue Code (für Machine Learning usw. verwende ich Python/uv) und freue mich auf künftige gRPC-Unterstützung sowie auf den Bundle-Befehl

• Erstaunlich, dass Deno auf FreeBSD immer noch nicht richtig läuft. Die Rust-basierten V8-Bindings sind noch nicht portiert

  • Ich frage mich, wie viele moderne JavaScript-Entwickler überhaupt FreeBSD nutzen

  • Früher galt Portabilität zwischen Unix-Systemen als Maßstab für sauberen Code, heute scheint Kompatibilität zwischen verschiedenen Unix-Systemen kaum noch ein Thema zu sein, was mich irritiert

  • Es scheint einen Eintrag in den FreeBSD-Ports zu geben

  • Dass für die Unterstützung von FreeBSD kein großer Aufwand betrieben wird, ist durchaus nachvollziehbar

• Eine Meinung ist, dass Deno in der Produktion nicht breiter eingesetzt wird, weil eine standardisierte Schwachstellen-Datenbank fehlt. Das lässt sich zwar mit 100% npm-Kompatibilität teilweise ausgleichen, aber dann fällt der Großteil der beliebten Deno-Pakete aus dem Raster. Grundsätzlich ist das Fehlen eines zentralen Paketmanagers — als absichtliches Design — eine Herausforderung. Es wird gefragt, ob es hierzu Fortschritte gibt

  • Falls das Fehlen einer Schwachstellen-Datenbank in der Produktion wirklich ein großes Problem wäre, könnte man nach derselben Logik auch C/C++ nicht verwenden. In der Praxis prüfen C/C++-Projekte Sicherheitsprobleme über sprachneutrale Datenbanken wie CVE oder GHSA. Außerdem wird bei C oft einfach irgendeine externe Datei vendored, ohne Versionen sauber nachzuverfolgen. Es gibt auch eine deno.lock-Datei, sodass diejenigen, die darauf achten, die verwendeten Versionen darüber gegen Schwachstellen-Datenbanken prüfen können

  • Das direkte Beziehen von Paketen per URL (z. B. von GitHub) ist bei Go ähnlich, daher würde dasselbe Problem auch für Go gelten

• Es gefällt mir, dass der Unterbefehl bundle wieder hinzugefügt wurde. Schön, dass man keine umständlichen Workarounds mehr braucht

• Überraschend, dass für das Bundling esbuild statt des Rust-basierten Rolldown verwendet wurde. Rolldown dürfte bald v1 erreichen

  • esbuild ist derzeit sehr stabil und ausgereift, während Rolldown sich noch schnell verändert, daher ist die Wahl von esbuild die naheliegendere

• Mir gefällt die Ausrichtung von Deno wirklich sehr, und ich finde, Node hätte ursprünglich so erscheinen sollen. Meine Sorge ist nur, dass Deno sich vom „Hype“ der Konkurrenten mitreißen lässt und ihnen am Ende einfach folgt, ohne den eigenen Weg beizubehalten

  • Andererseits wurde Deno selbst lange als ein auf „Hype“ basierender Konkurrent zu Node.js wahrgenommen

• Ich höre durchweg Gutes über Deno. Deshalb bekomme ich langsam Lust, doch mal js auszuprobieren

  • Heutzutage wäre es auch völlig okay, direkt mit TS anzufangen

• Aus Sicherheitsgründen drücke ich Deno die Daumen, aber mich hat gestört, dass auf der offiziellen Website Nutzern eine Installation per curl mywebsite.com/foo.sh | sh empfohlen wird. Natürlich hat jeder eine andere Risikotoleranz, aber wenn man eine Datei erst herunterlädt und dann ausführt, können zumindest der Nutzer selbst oder die Antivirensoftware sie noch prüfen. Das Node/Deno- plus npm-Ökosystem basiert grundsätzlich auf einem hohen Maß an Vertrauen. In der offiziellen Anleitung gibt es neben curl | sh auch die Option npm install -g deno; npm bietet immerhin minimale Integritätsprüfungen von Dateien und einfache Malware-Checks, was es relativ sicherer macht. Selbst wenn die Website deno.land auf Codebasis sicher ist, lässt sich operativ nie eine 100%ige Garantie geben, deshalb halte ich curl | sh nicht für eine bewährte Sicherheitspraxis

  • Ich teile diese Logik nicht. Die meisten Installationsskripte laden letztlich nur Binärdateien herunter und führen sie aus, die vom selben Autor stammen und Hunderte bis Millionen Codezeilen umfassen. Wenn man dem Autor so wenig vertraut, dass man sogar annimmt, der Server könnte nur an bestimmte IPs Malware ausliefern, dann könnte dieselbe Malware genauso gut schon auf Binärebene eingebaut sein — dann sollte man das Projekt grundsätzlich nicht verwenden. Dass die Debatte um curl | sh so verbreitet ist, liegt vielleicht daran, dass es ein einfaches und leicht wiederholbares Argument ist; das eigentliche Sicherheitsproblem ist eher das Prüfen von Millionen Codezeilen. Wenn man sogar MITM-Angriffe durch Behörden befürchtet, bleibt letztlich nur, sämtliches externes Vertrauen ins Internet aufzugeben

  • Es wird darauf hingewiesen, dass das Onboarding für neue Nutzer schwierig ist. Selbst wenn man empfiehlt, npm zu verwenden, muss npm zuerst installiert sein; die offizielle npm-Seite verweist auf die Installation von nvm, und selbst nvm nutzt curl | sh. Damit landet man über diesen Weg indirekt wieder beim selben Problem

  • In der Diskussion, ob npm install -g deno tatsächlich sicherer ist als curl | sh, läuft es im Kern auf die Frage hinaus: In welchen Server ist für Angreifer leichter einzudringen — in den npm-Server oder in den eigenen Server? Wenn man sicher sein kann, dass der eigene Server nicht kompromittiert wurde, gibt es keinen Grund, warum curl | sh unsicherer sein sollte als npm install. Aus Sicherheitssicht können am Ende beide Wege gleichermaßen verwundbar sein; wenn man es extrem sieht, ist das eigentliche Problem dann schon die Nutzung des Internets selbst

  • Kritik daran, dass Denos Sandbox-Implementierung nach Technik aus den 90ern wirke und ihre Nutzung keine gute Sicherheitspraxis sei

  • Die Frage, ob es reale erfolgreiche Angriffe über die Installationsmethode curl | sh gegeben hat