Astro 7 : nouveautés, performances, sécurité et retour de migration

Le meta-framework Astro passe en version 7 avec une priorité clairement affichée : réduire le temps nécessaire pour construire les sites, en particulier ceux qui contiennent des milliers de pages. Pour y parvenir, Astro s’appuie davantage sur Rust, adopte Vite 8 et remplace plusieurs briques historiques de sa chaîne de compilation.

D’après les benchmarks publiés par l’équipe, les builds sont de 15 à 61 % plus rapides selon les projets. Les sites riches en fichiers Markdown et MDX devraient profiter des gains les plus importants. Astro 7 apporte également un contrôle plus fin sur le traitement des requêtes, stabilise le cache des routes et améliore son fonctionnement avec les agents de code. Astro 7.4 complète cette évolution avec un rapport détaillé du temps de build, des services d’images séparés selon le mode de rendu et une première option de prérendu parallèle.

Mise à jour du 16 octobre 2026 : Astro 7.4 est disponible depuis le 15 octobre. Cette version ajoute astro build --timings, permet de choisir des services d’images distincts pour les pages prérendues et les pages générées à la demande, et expérimente le prérendu sur plusieurs threads. Elle relève aussi la version minimale de Node.js à 22.22.0.

Mise à jour du 8 septembre 2026 : Astro 7.3 est disponible depuis le 3 septembre. Cette version améliore les builds statiques incrémentaux, étend le logger aux services d’images et aux fournisseurs de cache, et permet de lancer plusieurs serveurs de prévisualisation. Astro 7.3.1, publiée quelques heures plus tard, corrige un blocage touchant les projets qui utilisent astro:assets.

Mise à jour du 31 août 2026 : Astro 7.2.8 corrige une vulnérabilité critique dans le traitement des images AVIF. La brève dédiée détaille les projets exposés et la mise à jour à appliquer.

Mise à jour du 20 août 2026 : Astro 7.2 est disponible depuis le 6 août. Cette version ajoute les builds statiques incrémentaux à titre expérimental, permet de désactiver complètement les sessions et étend le mode arrière-plan à astro preview.

Mise à jour du 17 juillet 2026 : Astro 7.1 est disponible depuis le 16 juillet. Cette version mineure apporte davantage de contrôle sur les règles CSP, les URL de pagination et le lancement de plusieurs serveurs de développement. Elle propose aussi de nouveaux leviers pour limiter la consommation de mémoire des grandes collections de contenu.

Sommaire

1. Astro 7.4 mesure les builds et parallélise le prérendu
2. Astro 7.3 affine les builds et les outils d’exécution
3. Astro 7.2 expérimente les builds statiques incrémentaux
4. Astro 7.1 donne plus de contrôle aux développeurs
5. Vite 8 et Rolldown
6. Un nouveau compilateur Astro écrit en Rust
7. Markdown et MDX passent à Sätteri
8. Le rendu par file d’attente devient la norme
9. Un contrôle complet du routage
10. Le cache des routes passe en stable
11. Des outils pensés pour les agents de code
12. Migration du site en pratique
13. Passer à Astro 7

Astro 7.4 mesure les builds et parallélise le prérendu

Publiée le 15 octobre 2026, Astro 7.4 fournit d’abord un nouvel outil pour comprendre les compilations lentes. La commande astro build --timings affiche la durée des grandes phases du build, des plugins Vite, du traitement Markdown, de la coloration syntaxique, du rendu des pages, des transformations d’images et des intégrations. Le rapport signale aussi les pages les plus lentes. Il devient ainsi possible d’identifier si le temps est consommé par le code du projet, une intégration ou la chaîne de compilation avant de tenter une optimisation.

La configuration des images peut désormais distinguer un service build d’un service runtime. Le premier traite les images des pages prérendues pendant le build et reste utilisé en développement. Le second prend en charge les pages générées à la demande ainsi que l’endpoint d’images en production. Un projet hybride peut donc conserver Sharp dans l’environnement Node.js de compilation et utiliser un CDN d’images sur un serveur ou une plateforme edge qui ne peut pas exécuter Sharp. Les projets concernés doivent mettre à jour @astrojs/cloudflare ou @astrojs/markdoc en même temps qu’Astro afin de conserver une version compatible.

Astro 7.4 propose également experimental.parallelPrerender. Cette option répartit le rendu des pages statiques entre plusieurs workers Node.js et peut mieux exploiter les processeurs multicœurs sur les sites dont le rendu est coûteux. Elle utilise par défaut tous les cœurs sauf un, mais le nombre de workers peut être limité pour contenir la consommation de mémoire. Les pages exécutées dans des workers distincts ne partagent pas nécessairement les variables définies au niveau des modules, et les propriétés transmises par getStaticPaths() doivent être sérialisables. L’option reste expérimentale et n’a pas d’effet lorsqu’un adaptateur fournit son propre système de prérendu, comme @astrojs/cloudflare.

Le prérequis Node.js évolue lui aussi. Astro et ses intégrations officielles demandent maintenant Node.js 22.22.0 au minimum. Une installation plus ancienne de Node.js 22 ne suffit donc plus. Il faut vérifier les versions utilisées localement, dans l’intégration continue et dans les images de conteneurs avant la mise à jour.

Parmi les autres changements, Astro 7.4 ajoute un handler notFound() pour les points d’entrée personnalisés, avertit lorsqu’un fournisseur de polices ne peut pas servir une variante configurée et expérimente une page de redirection personnalisable pour les builds statiques.

Annonce officielle d’Astro 7.4.

Astro 7.3 affine les builds et les outils d’exécution

Publiée le 3 septembre 2026, Astro 7.3 améliore surtout les outils de développement et les builds incrémentaux. L’option --ignore-lock fonctionne désormais avec astro preview, ce qui permet de lancer plusieurs serveurs de prévisualisation sur des ports différents, notamment pour les tests automatisés.

Le logger d’Astro est maintenant accessible aux services d’images personnalisés et aux fournisseurs de cache. La version améliore aussi la construction des sites qui génèrent beaucoup de pages. Les builds statiques incrémentaux peuvent profiter du rendu concurrent, y compris avec l’adaptateur Cloudflare.

Astro 7.3.1, publiée quelques heures plus tard, corrige une erreur qui empêchait certains projets utilisant astro:assets de démarrer ou de lancer un build. Astro 7.3.2, publiée le 8 septembre, a ensuite corrigé notamment l’échappement des valeurs dynamiques dans les balises <script> et <style> en MDX. Disponible depuis le 16 septembre, Astro 7.3.3 est elle aussi essentiellement corrective, avec des correctifs autour des images, des redirections, des builds incrémentaux et de Cloudflare, ainsi qu’une mise à jour de SVGO liée à un avis de sécurité. Astro 7.3.4, publiée le 22 septembre, corrige notamment un problème qui pouvait conduire les builds incrémentaux à rendre de nouveau des pages inchangées lorsque des modules ou du CSS compilé faisaient référence à des ressources empaquetées. Astro 7.3.5, publiée le 24 septembre, ajoute renderComponent() à l’API expérimentale AstroContainer afin de rendre un composant Astro avec ses styles et ses scripts intégrés.

Les correctifs se sont poursuivis en octobre. Astro 7.3.6, publiée le 6 octobre, rétablit notamment les fichiers ignorés par le loader glob() lorsque leur chemin contient # ou ?, fiabilise plusieurs scénarios de build, améliore la protection CSRF et valide l’en-tête Host avec security.allowedDomains dans l’adaptateur Node. Astro 7.3.7, publiée le 7 octobre, corrige une erreur de build avec certaines entrées Markdown, l’initialisation du fournisseur de cache et le rejet injustifié de requêtes interorigines JSON par security.checkOrigin. Enfin, Astro 7.3.8, publiée le 8 octobre, rend Astro.cache disponible dans les pages d’erreur personnalisées et rétablit la détection de fichiers modifiés pour certains motifs de collections de contenu. Elle fait surtout évoluer la chaîne de compilation interne : les transformations et le bundling passent par les outils de Vite fondés sur Oxc et Rolldown, sans dépendance directe à esbuild.

Annonce officielle d’Astro 7.3.

Astro 7.2 expérimente les builds statiques incrémentaux

Publiée le 6 août 2026, la version 7.2 s’attaque à la phase de génération des grands sites statiques. Astro 7 avait déjà réduit le temps consacré au bundling et au traitement du contenu. Le nouveau mode incrémental peut désormais éviter de régénérer les pages dont ni le code ni les données n’ont changé depuis le build précédent.

La fonction reste expérimentale et doit être activée avec experimental.incrementalBuild. Chaque chemin renvoyé par getStaticPaths() peut fournir une cacheKey. Astro réutilise la page uniquement si cette clé et le hash du graphe de modules de la route sont identiques à ceux du build précédent. Pour une collection de contenu, entry.digest constitue une clé adaptée puisqu’elle change avec le contenu de l’entrée.

Les routes qui ne déclarent pas de cacheKey continuent d’être rendues à chaque build. Le cache est conservé dans cacheDir, soit node_modules/.astro/ par défaut. Un pipeline d’intégration continue doit donc préserver ce répertoire entre deux exécutions pour profiter du mécanisme. En raison de son statut expérimental, il faut également vérifier que les données externes susceptibles de modifier une page sont bien prises en compte dans la clé.

Astro 7.2 ajoute aussi session: false. Ce réglage retire le runtime de session du bundle SSR lorsqu’un projet n’utilise pas Astro.session. Les adaptateurs Cloudflare, Netlify et Node n’installent alors pas leur gestionnaire par défaut. Même sans ce réglage, Astro supprime désormais ce code lorsque aucun pilote de session n’est configuré.

La commande astro preview --background reprend le fonctionnement introduit pour le serveur de développement. Le serveur de prévisualisation peut continuer à tourner en arrière-plan, écrire dans son propre fichier de logs et être contrôlé avec les sous-commandes correspondantes. Enfin, logger.entrypoint accepte maintenant un chemin relatif simple en plus d’une URL.

Annonce officielle d’Astro 7.2.

Astro 7.1 donne plus de contrôle aux développeurs

Publiée le 16 juillet 2026, la version 7.1 ne modifie pas les fondations techniques introduites avec Astro 7. Elle complète surtout plusieurs fonctions récentes et répond à des cas concrets rencontrés sur les sites statiques et les projets qui manipulent beaucoup de contenu.

Des règles CSP plus précises

La configuration de la Content Security Policy prend désormais en charge les directives script-src-elem, script-src-attr, style-src-elem et style-src-attr. Elles permettent de distinguer les éléments <script> et <style> des attributs HTML comme onclick ou style.

Un site peut ainsi autoriser certains styles inline dans les attributs sans appliquer la même règle aux feuilles de style externes. Cette granularité évite d’assouplir toute la politique pour résoudre un besoin limité.

Cette évolution pourrait notamment lever le blocage entre la CSP native d’Astro et les styles inline générés par Shiki. Ce point reste toutefois à confirmer par des tests.

Des URL de pagination adaptées au déploiement

La fonction paginate() accepte une nouvelle option format. Cette fonction reçoit chaque URL calculée par Astro et peut la transformer avant qu’elle ne soit exposée dans les liens next, prev, first et last.

Cette option répond notamment au cas des sites construits avec build.format: 'file' puis hébergés sans réécriture d’URL. Les liens peuvent maintenant recevoir explicitement l’extension .html :

return paginate(items, {
  pageSize: 10,
  format: (url) => `${url}.html`,
});

Plusieurs serveurs de développement pour un même projet

Astro 7 avait introduit un fichier de verrouillage afin d’éviter que des agents de code lancent plusieurs serveurs pour le même projet. Cette protection empêchait aussi un développeur de démarrer volontairement une seconde instance, par exemple pour comparer des logs.

Astro 7.1 ajoute l’option --ignore-lock pour ignorer ce contrôle :

astro dev --ignore-lock

Le serveur ainsi lancé fonctionne indépendamment de l’instance principale. Les commandes astro dev stop, astro dev status et astro dev logs ne permettent donc pas de le piloter.

Moins de mémoire pour les grandes collections

Le loader glob() rend normalement les entrées Markdown dès la synchronisation d’une collection, puis conserve le HTML produit en mémoire pour accélérer les builds suivants. Ce compromis devient coûteux lorsque la collection ou le contenu généré prend beaucoup de place.

L’option deferRender: true permet maintenant de reporter ce rendu jusqu’au moment où une page demande réellement l’entrée :

const docs = defineCollection({
  loader: glob({
    pattern: '**/*.md',
    base: 'src/content/docs',
    deferRender: true,
  }),
});

La synchronisation consomme alors moins de mémoire, au prix de la perte du cache du HTML rendu entre deux builds. Ce réglage s’applique collection par collection.

Astro expérimente en parallèle un stockage fragmenté avec experimental.collectionStorage: 'chunked'. Au lieu de regrouper toutes les données dans .astro/data-store.json, Astro les répartit dans plusieurs fichiers de 10 Mo. Cette option vise surtout les gros volumes de contenu déployés sur des plateformes qui limitent la taille des fichiers.

Une configuration plus souple du logger

Le logger personnalisé peut désormais être déclaré avec une URL dans astro.config.mjs. Cette forme permet de remplacer son point d’entrée au moment de l’exécution et de profiter des mécanismes fournis par Vite. Astro exporte aussi le type TypeScript AstroRuntimeLogger pour les fonctions qui reçoivent le logger à l’exécution.

Vite 8 et Rolldown

Astro 7 intègre Vite 8, dont la principale évolution est l’adoption de Rolldown. Ce bundler écrit en Rust remplace à la fois esbuild et Rollup dans Vite, tout en restant compatible avec leurs principales options et avec l’API des plugins Rollup.

Pour la majorité des projets Astro, cette transition devrait être transparente. Vite fournit une couche de compatibilité qui convertit notamment les configurations esbuild et rollupOptions. Les intégrations ou plugins qui utilisent des API internes de Vite devront en revanche être vérifiés avant la migration.

Pour aller plus loin sur le nouveau bundler, les gains de performance et la migration, consultez l’article consacré aux nouveautés de Vite 8.

Un nouveau compilateur Astro écrit en Rust

Le compilateur des composants .astro, auparavant écrit en Go, est entièrement remplacé par une implémentation en Rust. Le compilateur expérimental introduit avec Astro 6 devient donc le seul compilateur disponible dans Astro 7.

Le gain mesuré sur la compilation des seuls composants reste modéré, autour de 6 % sur le site de documentation d’Astro. Cette réécriture change toutefois certains comportements qu’il faut connaître avant une migration.

Le nouveau compilateur ne corrige plus silencieusement le HTML invalide. Une balise non fermée ou un attribut incomplet provoque maintenant une erreur. Il ne réorganise plus non plus les éléments pour tenter de produire un document valide. Enfin, les espaces entre les éléments suivent désormais les conventions de JSX. Deux éléments inline séparés par un retour à la ligne peuvent donc être rendus sans espace visible. Lorsqu’un espace est nécessaire, il faut l’ajouter explicitement avec {' '}.

Ce fonctionnement plus strict peut révéler des erreurs de template jusque-là masquées par l’ancien compilateur, mais il rend aussi le résultat produit plus prévisible.

Markdown et MDX passent à Sätteri

Astro 7 remplace la pipeline unified, fondée sur remark et rehype, par Sätteri pour traiter par défaut les fichiers Markdown et MDX. Ce processeur Rust était proposé en option depuis Astro 6.4. Il devient maintenant le choix standard.

Sätteri prend nativement en charge plusieurs fonctions qui nécessitaient auparavant des plugins, dont la syntaxe GitHub Flavored Markdown, les identifiants de titres, les notes de bas de page, les directives, les formules mathématiques, le frontmatter YAML ou TOML et les wikilinks. Son système de plugins peut cibler uniquement les types de nœuds utiles, ce qui évite de parcourir tout l’arbre de contenu à chaque transformation.

Les projets qui dépendent de plugins remark ou rehype ne sont pas bloqués. L’ancienne pipeline reste disponible avec @astrojs/markdown-remark, mais elle doit désormais être configurée explicitement.

Ce changement est l’une des principales sources d’amélioration pour les gros sites documentaires. D’après Astro, le passage à Sätteri a retiré plus d’une minute au build de sa documentation et à celui de la documentation Cloudflare.

Le rendu par file d’attente devient la norme

Le Queued Rendering, proposé à titre expérimental dans Astro 6, devient stable et activé par défaut. L’ancien moteur rendait récursivement chaque composant et ses enfants. La nouvelle implémentation place les éléments à traiter dans une file, puis les rend progressivement dans une seule boucle.

Cette stratégie consomme moins de mémoire et peut être environ 2,4 fois plus rapide sur les pages qui contiennent beaucoup d’expressions. Le gain sera plus limité sur des pages essentiellement statiques.

Un contrôle complet du routage avec src/fetch.ts

Astro 7 stabilise également l’Advanced Routing présenté dans Astro 6.3. La création d’un fichier src/fetch.ts permet de prendre la main sur tout le pipeline de requêtes avec une interface fondée sur le standard fetch.

Il devient ainsi possible de rediriger certaines requêtes vers un service externe, d’exécuter une authentification avant les Actions Astro ou de choisir précisément l’ordre des middlewares. L’API est aussi compatible avec Hono, dont les middlewares peuvent être composés avec les pages, les Actions et les fonctions d’internationalisation d’Astro.

Cette nouveauté vise surtout les applications qui dépassent le simple routage par fichiers. En l’absence de src/fetch.ts, Astro conserve son comportement habituel.

Le cache des routes passe en stable

Le Route Caching quitte lui aussi le statut expérimental. Astro propose maintenant une API indépendante de la plateforme pour mettre en cache les réponses générées à la demande. Les règles peuvent être définies dans une page avec Astro.cache, dans un endpoint avec context.cache ou globalement dans routeRules.

L’API gère notamment la durée de conservation, le stale-while-revalidate, l’invalidation par chemin et les tags. Elle s’intègre aux Live Content Collections, dont les loaders peuvent transmettre directement leurs informations de cache à Astro.

Astro fournit un provider en mémoire pour commencer. Des providers CDN expérimentaux sont également disponibles pour Netlify, Vercel et Cloudflare afin de servir les réponses directement depuis leur réseau edge. Le provider Cloudflare dépend toutefois d’une fonctionnalité encore en bêta privée.

Des outils pensés pour les agents de code

Astro 7 introduit plusieurs adaptations destinées aux outils de développement assistés par IA. La commande astro dev --background lance le serveur de développement comme un processus géré en arrière-plan. Astro peut détecter qu’il est exécuté par un agent et activer automatiquement ce mode.

Le serveur expose alors des commandes pour consulter son état, lire ses logs ou l’arrêter. Un fichier de verrouillage empêche le lancement accidentel de plusieurs instances et un endpoint /_astro/status permet de vérifier que le serveur est prêt.

Le logger devient aussi configurable et peut produire du JSON structuré avec astro dev --json. Cette sortie facilite le travail des agents, mais aussi l’envoi des logs d’une application SSR vers Kibana, CloudWatch ou Grafana Loki. Une API permet enfin de combiner plusieurs handlers pour conserver une sortie lisible dans le terminal tout en fournissant des données exploitables par d’autres outils.

Migration du site en pratique

Ce site étant construit avec Astro, sa migration a servi de test sur un projet réel contenant plusieurs centaines d’articles, de brèves, de guides et de pages générées statiquement. Le passage à Astro 7 s’est révélé assez simple, mais il a surtout mis en lumière plusieurs dépendances implicites et un problème d’organisation dans le code du projet.

Une mise à niveau automatique, puis quelques ajustements

La migration a été lancée sur une branche dédiée avec l’outil officiel :

npx @astrojs/upgrade

L’outil a mis à jour les dépendances et signalé les changements incompatibles. Il n’a modifié ni les templates ni la configuration Markdown. Le premier build a donc permis d’identifier les adaptations réellement nécessaires.

Le premier blocage concernait les anciennes options markdown.remarkPlugins, markdown.rehypePlugins et markdown.remarkRehype. Elles reposent sur le processeur unified, qui n’est plus installé par défaut avec Astro 7.

Le site utilisait rehype-external-links pour ajouter target="_blank" et les attributs rel adaptés aux liens externes. Installer @astrojs/markdown-remark aurait permis de conserver ce fonctionnement, mais aussi toute l’ancienne chaîne Markdown en JavaScript. Cette solution a fonctionné pendant un premier essai, puis a été écartée afin de conserver Sätteri.

Sätteri dispose de sa propre API de plugins HAST. La documentation officielle propose justement un exemple de traitement des liens externes, adapté ici aux besoins du site :

import { satteri } from '@astrojs/markdown-satteri';
import { defineHastPlugin } from 'satteri';

const externalLinks = defineHastPlugin({
  name: 'external-links',
  element: {
    filter: ['a'],
    visit(node, context) {
      const href = node.properties.href;
      const isExternal = typeof href === 'string'
        && (/^https?:\/\//.test(href) || href.startsWith('//'));

      if (isExternal) {
        context.setProperty(node, 'target', '_blank');
        context.setProperty(node, 'rel', ['noopener', 'noreferrer']);
      }
    },
  },
});

markdown: {
  processor: satteri({
    hastPlugins: [externalLinks],
  }),
}

Les anciens packages Markdown ont ensuite été retirés. Des tests ciblés ont confirmé que les liens externes conservaient leurs attributs, tandis que les liens internes et les ancres restaient inchangés.

Aligner les dépendances autour de Vite 8

La migration a également révélé que @tailwindcss/vite 4.2.1 ne déclarait pas encore sa compatibilité avec Vite 8. npm conservait donc une seconde installation de Vite 7 pour satisfaire ses dépendances.

La version 4.2.2 de Tailwind ajoute explicitement la compatibilité avec Vite 8. Le cœur et le plugin ont donc été mis à jour ensemble :

npm install @tailwindcss/vite@4.2.2 tailwindcss@4.2.2
npm install --save-dev vite@8.0.16

Après cette correction, Astro, Tailwind et vitefu utilisent la même installation de Vite.

Reproduire le véritable flux de déploiement

Un build local réussi ne suffisait pas à valider la migration. La reproduction du flux Docker complet a révélé deux autres dépendances cachées.

Le script de postbuild importait esbuild sans le déclarer dans package.json. Jusqu’à Astro 6, ce package était installé indirectement avec Vite. Comme Vite 8 utilise Rolldown, il a fallu déclarer esbuild explicitement :

npm install --save-dev esbuild

Le second problème venait de l’image node:22-alpine. Alpine repose sur musl, mais Sätteri 0.9.1 ne fournit pas de binding Linux musl. L’étape de construction utilise désormais une image Debian compatible glibc :

FROM node:22-bookworm-slim AS builder

L’image finale reste basée sur nginx:stable-alpine, car elle ne contient que les fichiers statiques produits par l’étape précédente. Le build Docker complet a ensuite validé l’installation, la génération des pages, les sitemaps, Pagefind et la minification des scripts.

Ce que la migration a réellement mis en évidence

Les premières mesures montraient un build Astro 7 légèrement plus rapide que le build Astro 6 réalisé avant la migration. Elles ne suffisent toutefois pas à isoler l’effet de la nouvelle version. Une seule exécution avait été réalisée pour chaque configuration et le temps total était largement dominé par le code du projet.

L’examen des logs a finalement révélé le principal problème. Plusieurs composants reconstruisaient, filtraient et triaient les mêmes collections pour chaque page. La sidebar recalculait les catégories, les tags, les dossiers et les contenus mis en avant. Les pages individuelles reparcouraient aussi les articles pour produire la navigation et les recommandations. Les pages de catégories et de tags reconstruisaient à leur tour leurs taxonomies.

Ces données sont maintenant préparées une seule fois pendant le build, puis partagées entre les routes. Les navigations et recommandations utilisent des index par URL, catégorie et tag. Les collections de guides, de dossiers et de glossaire suivent le même principe.

Cette optimisation a eu un effet bien plus important que l’écart observé pendant la migration du framework. Le build complet est passé de près de trois minutes à moins de vingt secondes sur la même machine. Une comparaison par empreinte SHA-256 a confirmé que les 587 fichiers HTML générés sont strictement identiques avant et après le changement. Le build Docker complet produit également le site, les sitemaps et l’index Pagefind sans erreur.

Ce résultat ne permet pas d’affirmer qu’Astro 7 est responsable de cette accélération. Le code optimisé n’a pas été reconstruit avec Astro 6 dans une configuration équivalente. La comparaison initiale reste donc un retour de migration utile, mais pas une mesure isolée des performances du framework.

Passer à Astro 7

La migration automatisée reste la méthode recommandée :

npx @astrojs/upgrade

Une mise à jour manuelle est également possible :

npm install astro@latest

Avant de migrer un projet existant, les principaux points à contrôler sont la validité des templates .astro, les espaces entre éléments inline, la compatibilité des plugins Vite et l’utilisation de plugins remark ou rehype. Les flags experimental.rustCompiler et experimental.queuedRendering peuvent être supprimés. Une configuration expérimentale du cache doit quant à elle être déplacée au niveau principal de astro.config.mjs.

Sources : Astro 7.4 · Astro 7.3 · Astro 7.3.1 · Astro 7.3.2 · Astro 7.3.3 · Astro 7.2 · Astro 7.1 · Astro 7.0.