Nitro v3.0.260603-beta : Commandes de Framework Personnalisées et Config defaultPreset

Nitro v3.0.260603-beta : Commandes de Framework Personnalisées et Config defaultPreset

lschvn

Le train des betas Nitro v3 continue d'avancer. Le build 3.0.260603-beta, le versioning daté signifie 3 juin 2026, est une petite release, mais deux de ses changements comptent pour quiconque construit un framework au-dessus de Nitro, ce qui depuis l'annonce de la beta v3 inclut TanStack Start et la prochaine majeure de Nuxt.

Les frameworks possèdent désormais preview et deploy

Nitro a toujours géré le build ; ce qui venait après restait l'affaire de la plateforme. Cette release permet aux plugins de framework d'enregistrer leurs propres commandes de preview et de déploiement, pour intégrer l'outillage spécifique à une plateforme dans le pipeline que les utilisateurs exécutent déjà.

Concrètement : si votre framework cible Cloudflare avec un workflow particulier, il peut maintenant l'exposer comme chemin canonique de preview/deploy, plutôt que de documenter une CLI séparée. Moins de « lancez notre autre outil après le build », plus un seul pipeline qui fait ce qu'il faut selon la plateforme.

defaultPreset : contrôler le fallback

Quand aucun preset de déploiement n'est configuré ni détecté, Nitro retombait sur un défaut codé en dur. La nouvelle option defaultPreset rend ce fallback explicite :

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

C'est surtout utile dans les monorepos et les presets de framework, où « aucun preset précisé » doit signifier quelque chose de spécifique à votre setup, pas le défaut du moment de Nitro.

Un cas limite de type-stripping corrigé

La release corrige aussi un bug subtil de résolution de modules : quand la résolution réessaie un chemin avec des extensions TypeScript ajoutées (.ts, .tsx), Nitro ne retire désormais que les extensions réellement réessayées, et plus toutes les extensions possibles. Cas limite, certes, mais du genre à produire un « module not found » incompréhensible dans exactement un fichier d'un gros projet.

Faut-il mettre à jour ?

Si vous êtes déjà sur la beta v3, oui, c'est une mise à jour incrémentale sans risque via npm i nitro@beta. Si vous êtes auteur de framework, les hooks de commandes personnalisées sont le vrai titre : c'est la première pièce du « bring your own framework » de la v3 qui dépasse le build pour toucher au déploiement. Pour tous les autres, c'est un bon rappel que la v3 itère vite, betas hebdomadaires datées, avant Nuxt 5 qui arrivera sur Nitro v3 et H3 v2.

Questions fréquentes

Articles connexes

Plus de couverture avec des sujets et tags en commun.

React Router v8 promeut ses Future Flags en valeurs par défaut, passe en ESM uniquement et abandonne `react-router-dom`
frameworks

React Router v8 promeut ses Future Flags en valeurs par défaut, passe en ESM uniquement et abandonne `react-router-dom`

React Router v8.0.0 (17 juin 2026) est la première version majeure sous le modèle de gouvernance ouverte (Open Governance) du projet et la première d'un rythme annuel planifié. Chaque indicateur `future.v8_*` de la v7 devient la valeur par défaut (middleware toujours activé, requêtes pass-through, API Vite Environment, découpage des modules de route), la base minimale passe à Node 22.22+, React 19.2.7+ et Vite 7+, tous les paquets sont publiés en ESM uniquement avec une cible ES2022, `react-router-dom` est supprimé, et les adaptateurs Node basculent vers un serveur fetch maintenu par Remix tandis que `create-react-router` abandonne son polyfill fetch pour le `fetch` natif.
Deno accueille `deno desktop` : sous-commande pour applications de bureau auto-contenues, basée sur WEF, avec Deno.BrowserWindow, DevTools unifiés et compilation croisée macOS, Windows et Linux
runtimes

Deno accueille `deno desktop` : sous-commande pour applications de bureau auto-contenues, basée sur WEF, avec Deno.BrowserWindow, DevTools unifiés et compilation croisée macOS, Windows et Linux

Deno a fusionné `deno desktop` le 16 juin 2026 (PR #33441), une nouvelle sous-commande qui transforme un projet Deno en application de bureau auto-contenue. La fonctionnalité embarque le backend WEF (CEF par défaut, plus WebView et winit brut), l'API Deno.BrowserWindow pour le cycle de vie de la fenêtre et les événements natifs, la détection automatique des frameworks Next, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start et Vite SSR, un multiplexeur CDP qui expose les deux isolats V8 dans une seule session DevTools, un système de mise à jour automatique avec patches bsdiff, et des sorties compilées .app/.dmg/.exe/.AppImage. Trois PR Deno plus petites sont arrivées le même matin : `deno link`/`unlink`, `deno test --shard`, et un `request_builder_hook` fetch pour les en-têtes `x-deno-fetch-token`/`cdn-loop`.
Fresh 2.3 : Zero JS par Défaut, View Transitions et Support WebSocket
runtimes

Fresh 2.3 : Zero JS par Défaut, View Transitions et Support WebSocket

Fresh 2.3 tient enfin sa promesse de 'zéro JavaScript par défaut', ajoute le support natif des View Transitions, des handlers WebSocket intégrés, l'injection de nonce CSP et le support de l'API Temporal dans les islands.

Commentaires

Connexion Connectez-vous pour participer à la conversation.

Pas encore de commentaires. Soyez le premier à partager vos pensées.