Découvrez Vinext, l'alternative à Next.js construite sur Vite

Vinext est un plugin Vite open source de Cloudflare qui réimplémente l’API de Next.js. Une base de code existante utilisant l’App Router ou le Pages Router peut ainsi être compilée et servie par Vite plutôt que par la chaîne d’outils de Next.js. Cloudflare a annoncé la version 1.0 le 28 septembre 2026.

De nombreuses équipes apprécient Next.js, mais pas l’hébergement vers lequel il les oriente. Et porter une application volumineuse vers un autre framework dans le seul but de changer d’hébergeur est difficile à justifier. Vinext propose une autre voie. Cet article présente ce que Vinext prend en charge, les cibles de déploiement possibles, les commandes exactes pour le tester sur votre propre application et les lacunes documentées par Cloudflare elle-même.

Qu’est-ce que Vinext et en quoi se distingue-t-il des autres alternatives à Next.js ?

Vinext est une réimplémentation de Next.js sur Vite, réalisée par Cloudflare. Le projet a débuté en février 2026 sous la forme d’une expérimentation d’une semaine pilotée par l’IA, puis a atteint la version 1.0 sept mois plus tard. Le README est explicite : il ne s’agit pas d’un fork. Le cœur a été écrit de zéro pour correspondre à l’API publique de Next.js.

Vinext constitue donc une option d’une autre nature que les alternatives à Next.js habituelles. Migrer vers React Router, Astro ou SvelteKit implique de réécrire les routes, le chargement des données et les composants. Vinext ne touche pas à ce code et ne modifie que ce qui le compile et le sert. Votre projet conserve l’apparence d’un projet Next.js, et c’est Vite qui fait le travail en arrière-plan.

Que prend en charge Vinext ?

Vinext couvre les deux routeurs ainsi que les principales fonctionnalités serveur du Next.js moderne. L’annonce de la version 1.0 et le README mentionnent la prise en charge des éléments suivants :

• App Router, Pages Router et applications hybrides utilisant les deux
• React Server Components et Server Actions
• Middleware, routes d’API et route handlers
• Revalidation ISR
• Prérendu au moment du build via generateStaticParams() et getStaticPaths()
• Export statique avec output: "export"

Le README cible Next.js 16.x et indique vite ^8.0.0 comme dépendance pair (peer dependency).

Cloudflare exprime la compatibilité de Vinext avec Next.js de deux manières différentes, et ces deux chiffres ne mesurent pas la même chose. L’article de la version 1.0 fait état de plus de 99 % de compatibilité aux tests, mais uniquement pour les fonctionnalités les plus demandées par les clients, et en excluant Cache Components. Le README indique quant à lui que « ~94 % de la surface de l’API de Next.js 16 bénéficie d’une prise en charge totale ou partielle ». Ces deux chiffres proviennent de Cloudflare. Aucun ne remplace un test sur votre propre application.

Où peut-on déployer Vinext ?

Vinext se déploie nativement sur Cloudflare Workers, et l’article de la version 1.0 précise qu’il fonctionne avec l’offre gratuite de Workers. Ce même article cite Netlify et AWS Lambda comme cibles de déploiement. Le README en explique le mécanisme : Workers est pris en charge directement par @vinext/cloudflare, tandis que Vercel, Netlify, AWS et Deno Deploy sont accessibles en ajoutant le plugin Vite de Nitro. Aucun adaptateur natif pour Netlify ou Lambda n’intervient.

Une configuration minimale ajoute un seul plugin :

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [vinext()],
});

Pour cibler un hébergeur autre que Cloudflare, installez nitro et ajoutez son plugin :

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";
import { nitro } from "nitro/vite";

export default defineConfig({
  plugins: [vinext(), nitro()],
});

npm install nitro
NITRO_PRESET=netlify npx vite build

Comment tester Vinext sur une application Next.js existante

Tester Vinext sur une application existante ne demande que deux commandes, et aucune d’elles n’interrompt votre workflow Next.js actuel. Exécutez-les sur une branche dédiée :

npx vinext check
npx vinext init

vinext check analyse le projet et signale les incompatibilités connues avant toute modification. vinext init est non destructif : next dev continue donc de fonctionner parallèlement à la nouvelle configuration. La commande demande une cible de déploiement et propose Cloudflare par défaut. Depuis la version 1.0, les configurations Cloudflare utilisent par défaut la CLI cf avec un fichier typé cloudflare.config.ts. Pour conserver plutôt l’ancienne configuration Wrangler, passez l’option --legacy-wrangler-cloudflare-init.

Démarrer une nouvelle application Vinext

Pour un nouveau projet, générez l’application, lancez-la, compilez-la, puis déployez-la :

npm create vinext-app@latest my-app
npx vite dev
npx vite build
npx @vinext/cloudflare deploy

La version 1.0 ajoute une option --warm-cache à la commande de déploiement. Celle-ci téléverse la nouvelle version avec 0 % du trafic, interroge à travers elle les pages pouvant être mises en cache afin de remplir les caches, et ne la promeut qu’ensuite.

Quelles sont les limites et les lacunes connues de Vinext ?

La section Known gaps du README recense quatre domaines dans lesquels Vinext n’égale pas encore Next.js : Cache Components, l’optimisation des images et des polices au moment du build, les modules natifs en développement avec l’App Router, et certaines configurations de route propres à une plateforme. Cloudflare indique travailler encore sur ces quatre points : aucun ne constitue donc une limite définitive.

• Cache Components et PPR : "use cache" fonctionne en partie, mais le modèle complet cacheComponents n’est pas finalisé. Les profils de cache, les tags, les shells partiels, la reprise (resuming), le préchargement (prefetching) ainsi qu’une partie de la mise en cache en dev et au build peuvent encore se comporter différemment de Next.js.
• Images et polices : sur Cloudflare, les images peuvent être optimisées au moment où elles sont demandées. Vinext ne reproduit pas encore l’intégralité du pipeline d’images que Next.js exécute au build, et les polices sont chargées à l’exécution plutôt que traitées pendant le build.
• Modules natifs : des paquets tels que sharp, resvg, satori, lightningcss et @napi-rs/canvas peuvent ne pas fonctionner dans l’environnement de développement RSC de Vite. Les builds de production en prennent en charge davantage que le mode dev.
• Configuration des routes : Vinext ignore les paramètres de route runtime et preferredRegion.

Le README précise également que Vinext n’est pas encore un remplacement direct (drop-in replacement) pour toutes les applications.

Qui devrait adopter Vinext, et qui devrait attendre

Vinext convient aux équipes qui souhaitent continuer à développer avec Next.js sans être liées à un seul hébergeur. Les sources ne s’accordent pas entièrement sur sa maturité pour la production. L’annonce de Cloudflare qualifie la version 1.0 de prête pour la production, tandis que le README répond « Oui, avec prudence » et rappelle que Vinext présente encore des lacunes de compatibilité et n’a pas encore fait ses preuves sur tous les types d’applications Next.js en production.

• Adoptez-le si votre application utilise les deux routeurs, les RSC, les Server Actions et l’ISR, et que vous souhaitez déployer sur Workers ou via Nitro.
• Attendez si vous dépendez fortement de Cache Components, du PPR ou de la sémantique de "use cache", comme les tags et les profils.
• Envisagez OpenNext si vous avez besoin d’une maturité éprouvée en production. Le README de Vinext explique qu’OpenNext s’appuie sur la sortie de next build, ce qui lui permet de couvrir une plus grande partie de l’API de Next.js, et qu’il bénéficie d’un historique bien plus long.

Conclusion

Avec Vinext, vous pouvez quitter Vercel sans réécrire votre application Next.js. Vous devez toutefois accepter des lacunes documentées, principalement autour de Cache Components. Pour savoir s’il vous convient, créez une branche, exécutez npx vinext check, comparez les points signalés avec les lacunes connues, puis lancez npx vinext init et comparez le comportement avec celui de next dev. Si vous souhaitez également migrer le reste de votre chaîne d’outils, consultez Getting Started with Vite+ (le README indique vp exec vinext-cloudflare deploy pour les projets Vite+). Pour le workflow cloudflare.config.ts mis en place par init, reportez-vous à A Practical Guide to Cloudflare’s New cf CLI.

FAQ

Puis-je conserver ma configuration webpack personnalisée ou ma configuration next/jest en passant à Vinext ?

Non. Vinext s'exécute sur Vite : les configurations Turbopack et webpack ne s'appliquent donc pas, et les loaders ou plugins webpack personnalisés doivent être remplacés par des plugins Vite. Le README de Vinext indique que next/jest n'est pas pris en charge et recommande Vitest à la place. AMP n'est pas non plus pris en charge, useAmp() renvoyant toujours false, et l'ancienne commande next export est remplacée par le paramètre output: 'export' dans la configuration Next.js.

Quelles versions de React et de Vite Vinext requiert-il ?

Vinext déclare des dépendances pair sur react ^19.3.1, react-dom ^19.3.1, react-server-dom-webpack ^19.3.1 et vite ^8.0.0, et cible Next.js 16.x. Les projets utilisant l'App Router doivent également avoir @vitejs/plugin-rsc installé. Vinext enregistre automatiquement ce plugin lorsqu'il détecte un répertoire app : ajouter votre propre appel à rsc() fait donc échouer le build avec une erreur de plugin en double, sauf si vous passez rsc: false à vinext().

Que modifie vinext init dans un projet Next.js existant ?

vinext init ajoute 'type': 'module' au fichier package.json et renomme les fichiers de configuration CommonJS, par exemple postcss.config.js en postcss.config.cjs, afin d'éviter les conflits ESM. La commande installe également les paquets Vite et Vinext et ajoute les scripts dev:vinext, build:vinext et start:vinext à côté des scripts Next.js existants. Les scripts d'origine étant conservés, next dev et le serveur de développement Vinext peuvent s'exécuter depuis la même base de code pour une comparaison côte à côte.

Avec Vinext sur Cloudflare, revalidateTag sert-il des pages périmées pendant leur régénération ?

Oui, depuis les versions 1.1 d'octobre 2026, lorsque vous passez un profil de cache, par exemple revalidateTag(tag, 'max'). Les versions précédentes purgeaient les pages correspondantes de Workers Cache, si bien que la requête suivante devait attendre un rendu complet. Désormais, Workers Cache et le Response Store marquent ces entrées comme périmées et continuent de servir la version en cache pendant sa régénération en arrière-plan, comme le fait Next.js. Appeler revalidateTag avec un tag seul, ou avec expire: 0, fait toujours expirer les entrées immédiatement. Les entrées 'use cache' périmées sont elles aussi servies pendant leur régénération.