Astro 6.4 : Processeur Markdown Rust Sätteri et Temps de Build Réduits

Astro 6.4 : Processeur Markdown Rust Sätteri et Temps de Build Réduits

lschvn

Astro 6.4 est arrivé le 28 mai avec une fonctionnalité majeure qui compte pour tout site à fort contenu : un processeur markdown optionnel basé sur Rust appelé Sätteri, conçu pour remplacer l'écosystème unified sur les sites contenant des centaines ou des milliers de fichiers Markdown.

TLDR

  • La nouvelle option de configuration markdown.processor permet de remplacer le pipeline markdown d'Astro
  • @astrojs/markdown-satteri est un processeur basé sur Rust qui accélère drastiquement les builds pour les sites à fort contenu markdown
  • La structure du répertoire serveur est désormais préservée indépendamment via preserveBuildServerDir
  • Les routes SSR on-demand passent maintenant correctement au handler suivant quand une route pré-rendue correspond mais ne peut servir la requête

Le Problème : Unified Est Lent à Grande Échelle

Le pipeline markdown d'Astro a toujours utilisé l'écosystème unified, plugins remark et rehype, qui est puissant mais notoirement lent à grande échelle. Les sites avec de nombreux fichiers Markdown ou MDX finissent avec des temps de build de plusieurs minutes car le processeur unified analyse et transforme le contenu séquentiellement.

Astro 6.4 introduit markdown.processor comme nouvelle option de configuration de haut niveau qui remplace les champs existants remarkPlugins et rehypePlugins :

// astro.config.mjs
import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';
import remarkToc from 'remark-toc';

export default defineConfig({
  markdown: {
    processor: unified({
      remarkPlugins: [remarkToc],
    }),
  },
});

Les configurations existantes utilisant remarkPlugins, rehypePlugins, gfm et smartypants fonctionnent toujours, elles sont désormais dépréciées et seront supprimées dans une future version majeure.


Sätteri : L'Alternative Rust

En parallèle de la nouvelle option de configuration, Astro livre @astrojs/markdown-satteri, un processeur alimenté par la bibliothèque Rust Sätteri :

// astro.config.mjs
import { defineConfig } from 'astro/config';
import { satteri } from '@astrojs/markdown-satteri';

export default defineConfig({
  markdown: {
    processor: satteri({
      features: { directive: true },
    }),
  },
});

Sätteri est écrit en Rust et exclut délibérément l'écosystème de plugins remark/rehype. À la place, il supporte nativement les plugins MDAST et HAST, les plugins existants doivent être réécrits pour fonctionner avec le nouveau processeur, mais le gain en rapidité d'analyse est significatif à grande échelle.

Les sites avec des milliers de fichiers markdown devraient voir les améliorations les plus spectaculaires. L'équipe Astro cite le projet Sätteri directement sur satteri.bruits.org.


Préservation Indépendante du Répertoire Serveur

Astro 6.4 ajoute preserveBuildServerDir aux features de l'adapter API. Cela reflète l'option existante preserveBuildClientDir mais pour le répertoire de sortie serveur :

setAdapter({
  name: 'my-adapter',
  adapterFeatures: {
    buildOutput,
    preserveBuildClientDir: true,
    preserveBuildServerDir: true,
  },
});

Auparavant, préserver le répertoire client affectait automatiquement la structure du répertoire serveur. Maintenant les adapters peuvent conserver une disposition cohérente dist/client/ et dist/server/ indépendamment.


Correctif de Fallthrough SSR

Un cas limite de longue date dans le rendu on-demand d'Astro est désormais corrigé. Quand une route dynamique pré-rendue et une route dynamique SSR partageaient le même pattern d'URL, les requêtes vers des chemins non pré-rendus retournaient 404 au lieu de passer au handler SSR. La correction ajoute une logique de fallthrough : quand une route dynamique pré-rendue correspond mais ne peut servir la requête, Astro essaie maintenant les routes suivantes.


FAQ

Dois-je passer à Sätteri immédiatement ? Si votre site est suffisamment rapide avec l'écosystème unified, restez dessus. Si vous avez des centaines de fichiers markdown et des temps de build douloureux, Sätteri mérite un test. Attention : les plugins remark/rehype ne fonctionnent pas avec Sätteri.

Sätteri supporte-t-il toutes les fonctionnalités markdown d'Astro ? Il supporte les directives. Le GFM complet (tableaux, listes de tâches, barré) et smartypants sont configurables via les options propres à Sätteri.

Qu'en est-il des configs remarkPlugins existantes ? Elles fonctionnent encore en 6.4 mais sont dépréciées. Astro recommande de migrer proactivement vers la nouvelle API processor.

Articles connexes

Plus de couverture avec des sujets et tags en commun.

Next.js 16.2 Stabilise l'API Adaptateur, et c'est Plus Important que Ça en a l'Air
frameworks

Next.js 16.2 Stabilise l'API Adaptateur, et c'est Plus Important que Ça en a l'Air

Vercel, Netlify, Cloudflare, AWS et Google Cloud ont tous signé le même contrat public. Next.js 16.2 fait du déploiement multi-plateforme une fonctionnalité de première classe.
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.
Vite 8.1 Beta : imports `.wasm` directs, `build.chunkImportMap` et rename `server.hmr` → `server.ws`
typescript

Vite 8.1 Beta : imports `.wasm` directs, `build.chunkImportMap` et rename `server.hmr` → `server.ws`

Vite 8.1.0-beta.0 (15 juin 2026) est la première beta de la ligne 8.1. Elle livre le standard WASM ESM Integration en imports `.wasm` directs, une option build.chunkImportMap qui exploite les import maps pour améliorer les taux de cache des chunks, l'intégration avec Vite Task pour du cache de build sans configuration, le support des dépendances de plugin lightningcss, et un breaking rename qui déplace toutes les options `server.hmr` vers `server.ws`.

Commentaires

Connexion Connectez-vous pour participer à la conversation.

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