Nitro v3.0.260603-beta: Custom Framework Commands und defaultPreset-Config

Nitro v3.0.260603-beta: Custom Framework Commands und defaultPreset-Config

lschvn

Der Beta-Zug von Nitro v3 rollt weiter. Build 3.0.260603-beta, das datumsbasierte Versionsschema steht für den 3. Juni 2026, ist ein kleines Release, aber zwei Änderungen sind für alle relevant, die ein Framework auf Nitro aufbauen. Und das sind seit der v3-Beta-Ankündigung unter anderem TanStack Start und das kommende Nuxt-Major.

Frameworks besitzen jetzt preview und deploy

Nitro hat schon immer den Build übernommen; was danach kam, war Sache der Plattform. Dieses Release erlaubt Framework-Plugins, eigene Preview- und Deploy-Kommandos zu registrieren, plattformspezifisches Tooling wandert damit in genau die Pipeline, die Nutzer ohnehin schon ausführen.

Konkret: Zielt ein Framework etwa mit einem eigenen Workflow auf Cloudflare, kann es diesen jetzt als kanonischen preview/deploy-Pfad anbieten, statt eine separate CLI zu dokumentieren. Weniger „nach dem Build noch unser anderes Tool ausführen", mehr eine Pipeline, die je Plattform das Richtige tut.

defaultPreset: den Fallback kontrollieren

Wenn kein Deployment-Preset konfiguriert und keines erkannt wurde, fiel Nitro bisher auf einen hartkodierten Default zurück. Die neue Option defaultPreset macht diesen Fallback explizit:

export default defineNitroConfig({
  defaultPreset: "cloudflare_module",
});

Am nützlichsten ist das in Monorepos und Framework-Presets, wo „kein Preset angegeben" etwas Bestimmtes für das eigene Setup bedeuten soll, und nicht das, was Nitro gerade als Default wählt.

Ein Type-Stripping-Grenzfall, behoben

Das Release behebt außerdem einen subtilen Bug in der Modulauflösung: Wenn die Auflösung einen Pfad mit angehängten TypeScript-Endungen (.ts, .tsx) erneut versucht, entfernt Nitro jetzt nur noch die tatsächlich probierten Endungen, nicht mehr alle möglichen. Ein Grenzfall, aber von der Sorte, die in genau einer Datei eines großen Projekts ein rätselhaftes „module not found" erzeugt.

Lohnt das Update?

Wer schon auf der v3-Beta ist: ja, ein gefahrloses inkrementelles Update per npm i nitro@beta. Für Framework-Autoren sind die Custom-Command-Hooks die Schlagzeile: das erste Stück der „Bring your own framework"-Geschichte von v3, das über den Build hinaus bis ins Deployment reicht. Für alle anderen ist es eine gute Erinnerung daran, dass v3 schnell iteriert, wöchentliche, datierte Betas, auf dem Weg zu Nuxt 5 auf Nitro v3 und H3 v2.

Häufig gestellte Fragen

Verwandte Artikel

Weitere Berichterstattung zu ähnlichen Themen und Tags.

React Router v8 stuft seine Future Flags zu Standardwerten hoch, wird rein ESM und legt `react-router-dom` ab
frameworks

React Router v8 stuft seine Future Flags zu Standardwerten hoch, wird rein ESM und legt `react-router-dom` ab

React Router v8.0.0 (17. Juni 2026) ist das erste Major Release unter dem Open-Governance-Modell des Projekts und das erste in einem geplanten Jahresrhythmus. Jedes `future.v8_*`-Flag aus v7 wird zum Standard (immer aktiviertes Middleware, Pass-Through-Requests, die Vite-Environment-API, Route-Modul-Splitting), die Baseline steigt auf Node 22.22+, React 19.2.7+ und Vite 7+, alle Pakete erscheinen rein als ESM mit ES2022 als Ziel, `react-router-dom` wird entfernt und die Node-Adapter wechseln zu einem von Remix gepflegten Fetch-Server, während `create-react-router` seinen Fetch-Polyfill durch nativen `fetch` ersetzt.
Deno bringt `deno desktop` mit: WEF-basierter Unterbefehl für eigenständige Desktop-Apps mit Deno.BrowserWindow, vereinten DevTools und Cross-Compile für macOS, Windows und Linux
runtimes

Deno bringt `deno desktop` mit: WEF-basierter Unterbefehl für eigenständige Desktop-Apps mit Deno.BrowserWindow, vereinten DevTools und Cross-Compile für macOS, Windows und Linux

Deno hat `deno desktop` am 16. Juni 2026 zusammengeführt (PR #33441), einen neuen Unterbefehl, der ein Deno-Projekt in eine eigenständige Desktop-Anwendung verwandelt. Das Feature liefert das WEF-Backend (standardmäßig CEF, plus WebView und rohem winit), die Deno.BrowserWindow-API für Fenster-Lebenszyklus und native Events, Framework-Auto-Erkennung für Next, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start und Vite SSR, einen CDP-Multiplexer, der beide V8-Isolate in einer einzigen DevTools-Session anzeigt, einen Auto-Updater mit bsdiff-Patches und cross-kompilierte .app/.dmg/.exe/.AppImage-Outputs. Drei kleinere Deno-PRs landeten am selben Morgen: `deno link`/`unlink`, `deno test --shard` und ein fetch `request_builder_hook` für `x-deno-fetch-token`/`cdn-loop`-Header.
Fresh 2.3: Zero JS Standard, View Transitions und WebSocket-Support
runtimes

Fresh 2.3: Zero JS Standard, View Transitions und WebSocket-Support

Fresh 2.3 hält endlich sein Versprechen von 'standardmäßig Null JavaScript', fügt native View-Transitions-Unterstützung hinzu, bringt integrierte WebSocket-Handler, CSP-Nonce-Injection und Temporal-API-Support für Islands.

Kommentare

Anmelden Melden Sie sich an, um an der Diskussion teilzunehmen.

Noch keine Kommentare. Seien Sie der Erste, der seine Gedanken teilt.