Migrer depuis Next.js

bext sert nativement les applications Next.js. Il remplace le runtime Node.js et next start par un moteur SSR natif Rust, un cache ISR et un serveur HTTP. La plupart des applications Next.js migrent en moins d'une heure sans aucune modification de code dans vos composants React.

Cartographie des fonctionnalités#

Quels changements#

1. Supprimez next.config.js (ou conservez-le pour next build uniquement). Le comportement d'exécution est désormais configuré dans bext.config.toml.
2. Ajoutez bext.config.toml à la racine de votre projet.
3. Remplacez next start par bext-server run dans vos scripts de déploiement.
4. Supprimez le runtime Node.js de votre image de production Docker (facultatif mais permet d'économiser environ 100 Mo).

Ce qui reste le même#

• Votre structure de répertoires pages/ ou app/
• Tous les composants, hooks et code côté client React
• Modules CSS, Tailwind, composants stylisés
• getStaticProps, getServerSideProps, generateStaticParams
• Actions du serveur et composants du serveur
• Répertoire d'actifs statiques public/

Migration étape par étape#

1. Installez bext#

curl -fsSL https://bext.dev/install | sh

2. Créez votre application Next.js#

# Build as usual — bext consumes the Next.js build output
next build

Ou laissez bext gérer la construction :

bext-server build

3. Créez bext.config.toml#

[server]
listen = "0.0.0.0:3000"
static_dir = ".next/static"

[render]
bundle_path = ".next/server"
workers = 4

[cache.isr]
max_entries = 10_000
default_ttl_ms = 60_000
default_swr_ms = 3_600_000

4. Traduire les réécritures et les redirections#

suivant.config.js :

module.exports = {
  async rewrites() {
    return [
      { source: '/blog/:slug', destination: '/posts/:slug' },
    ];
  },
  async redirects() {
    return [
      { source: '/old-path', destination: '/new-path', permanent: true },
    ];
  },
};

bext.config.toml :

[[route_rules]]
pattern = "/blog/:slug"
rewrite = "/posts/:slug"

[[route_rules]]
pattern = "/old-path"
action = "redirect"
redirect = "/new-path"
redirect_status = 301

5. Traduire les en-têtes personnalisés#

suivant.config.js :

module.exports = {
  async headers() {
    return [
      {
        source: '/api/:path*',
        headers: [{ key: 'Cache-Control', value: 'no-store' }],
      },
    ];
  },
};

bext.config.toml :

[[route_rules]]
pattern = "/api/**"
render = "ssr"
headers = { "cache-control" = "no-store" }

6. Démarrez bext#

bext-server run

Visitez http://localhost:3000 et vérifiez que vos pages s'affichent correctement.

7. Exécutez votre suite de tests#

Exécutez vos tests d'intégration existants et vos tests E2E (Playwright, Cypress) sur le serveur bext. La sortie HTML doit être identique.

Problèmes courants#

next/dynamic avec ssr: false - Fonctionne comme prévu. Le composant est ignoré pendant SSR et rendu côté client. Aucun changement nécessaire.

server.js personnalisé -- Si vous disposez d'un serveur Node.js personnalisé ( server.js ), vous ne pouvez pas l'utiliser directement avec bext. Au lieu de cela, déplacez votre logique de serveur personnalisée vers les plugins bext ou utilisez bext comme proxy inverse sur votre serveur personnalisé :

[server]
upstream = "http://127.0.0.1:3001"   # your custom server.js

next.config.js personnalisation du webpack – La configuration du webpack affecte uniquement next build, qui s'exécute toujours dans Node.js. bext ne remplace pas l’étape de génération, uniquement le runtime. Les personnalisations de votre webpack continuent de fonctionner.

getServerSideProps avec appels de base de données -- Ceux-ci s'exécutent à l'intérieur de l'isolat V8. Si vous utilisez des API spécifiques à Node.js (par exemple, fs, net ), elles ne seront pas disponibles. Utilisez le mode proxy en amont de bext ou déplacez la récupération de données vers une route API.

Middleware NextResponse.rewrite() -- bext n'évalue pas middleware.ts comme JavaScript en direct. Il analyse le fichier à la recherche d'annotations de commentaires ( // @bext-redirect, // @bext-rewrite ) et applique ces règles statiques. Rediriger/réécrire proprement les ports middleware vers les annotations ou [[route_rules]] ; les middlewares qui nécessitent une véritable logique de temps de requête doivent être migrés vers un plugin bext (QuickJS ou WASM).

En rapport#

• Pipeline de rendu PRISM — comment fonctionne le moteur SSR du bext sous le capot
• Next.js à la demande — ISR à la demande et invalidation du cache pour les routes Next.js
• Mise en cache — Cache ISR, obsolète pendant la revalidation et invalidation basée sur les balises
• Actions du serveur — comment les fonctions "use server" sont gérées
• Extensions — portage de la logique middleware.ts vers des plugins QuickJS ou WASM
• Référence de configuration — schéma bext.config.toml complet

Links#

• prochainjs.org — documentation officielle Next.js