Auf Astro v6 aktualisieren

Dieser Leitfaden hilft dir bei der Migration von Astro v5 auf Astro v6.

Musst du ein älteres Projekt erst auf Version 5 aktualisieren? Sieh dir unseren Leitfaden zur Migration älterer Projekte (EN) an.

Möchtest du die Dokumentation zu Version 5 einsehen? Besuche diese ältere Version der Dokumentationsseite (nicht mehr gepflegter Snapshot v5.18.0).

Aktualisiere Astro

Aktualisiere die Astro-Version deines Projekts mithilfe deines Paketmanagers auf die neueste Version:

npm

# Astro und die offiziellen Integrationen gemeinsam aktualisieren
npx @astrojs/upgrade

pnpm

# Astro und die offiziellen Integrationen gemeinsam aktualisieren
pnpm dlx @astrojs/upgrade

Yarn

# Astro und die offiziellen Integrationen gemeinsam aktualisieren
yarn dlx @astrojs/upgrade

Bei Bedarf kannst du deine Astro-Integrationen auch manuell aktualisieren (EN). Möglicherweise musst du auch andere Abhängigkeiten in deinem Projekt aktualisieren.

Musst du fortfahren?

Nach dem Upgrade von Astro musst du möglicherweise überhaupt keine Änderungen an deinem Projekt vornehmen!

Solltest du jedoch Fehler oder unerwartetes Verhalten feststellen, schau bitte unten nach, was sich geändert hat und in deinem Projekt möglicherweise aktualisiert werden muss.

Astro v6.0 enthält möglicherweise inkompatible Änderungen sowie die Entfernung und Abkündigung einiger Funktionen.

Falls dein Projekt nach dem Upgrade auf Version 6.0 nicht wie erwartet funktioniert, findest du in dieser Anleitung einen Überblick über alle inkompatiblen Änderungen sowie Anweisungen zur Aktualisierung deines Projekts.

Die vollständigen Versionshinweise findest du im Astro-Changelog.

Aktualisierung von Abhängigkeiten

Größere Aktualisierungen der Abhängigkeiten von Astro können zu inkompatiblen Änderungen in deinem Projekt führen.

Node 22

Implementierungs-PR: feat!: drop node 18 and 20 (#14427)

Node 18 hat im März 2025 das Ende seiner Lebensdauer erreicht, und für Node 20 ist das Ende der Lebensdauer für April 2026 vorgesehen.

Astro v6.0 stellt die Unterstützung für Node 18 und Node 20 komplett ein, damit alle Astro-Nutzer die moderneren Funktionen von Node nutzen können.

Was soll ich tun?

Stelle sicher, dass sowohl deine Entwicklungsumgebung als auch deine Produktionsumgebung Node 22.12.0 oder höher verwenden.

1. Überprüfe deine lokale Node-Version mit folgendem Befehl:

   node -v

2. Schau in der Dokumentation deiner Bereitstellungsumgebung (EN) nach, ob Node 22 dort unterstützt wird.

   Du kannst Node 22.12.0 für dein Astro-Projekt entweder in einer Dashboard-Konfigurationseinstellung oder in einer .nvmrc-Datei festlegen.

   .nvmrc

   22.12.0

Vite 7.0

Implementierungs-PR: feat: update vite (#14445)

Astro v6.0 wechselt zu Vite v7.0 als Entwicklungsserver und Produktions-Bundler.

Was soll ich tun?

Wenn du Vite-spezifische Plugins, Konfigurationen oder APIs verwendest, schau dir den Vite-Migrationsleitfaden an, um dich über inkompatible Änderungen zu informieren, und aktualisiere dein Projekt bei Bedarf.

Für die Verwendung von Astro’s getViteConfig()-Helper (EN) ist mindestens Vitest v3.2 oder v4.1 Beta 5 erforderlich.

Vite-Environment-API

Implementierungs-PR: feat: integrate vite environments (#14306)

Astro v6.0 bringt wesentliche Änderungen daran mit sich, wie Astro verschiedene Laufzeitumgebungen (Client, Server und Prerender) verwaltet, nachdem intern eine Umstrukturierung vorgenommen wurde, um die neue Environment-API von Vite zu nutzen.

Was soll ich tun?

Betreuer von Integrationen und Adaptern sollten besonders auf Änderungen achten, die diese Teile der Integrations-API und der Adapter-API betreffen (alle Details findest du weiter unten zusammen mit anderen kompatibilitätsbrechenden Änderungen an diesen APIs):

• Konfigurationspfad für den Namen der Rollup-Ausgabedatei
• Integrations-Hooks und HMR-Zugriffsmuster
• SSRManifest-Struktur
• Routen mit RouteData erstellen
• URLs mit prozentkodierten Prozentzeichen (z. B. %25)
• Virtuelles Modul astro:ssr-manifest
• NodeApp aus astro/app/node
• loadManifest() und loadApp() aus astro/app/node
• createExports() und start()

Zod 4

Astro v6.0 wird auf Zod 4 aktualisiert – ein umfangreiches Update der Abhängigkeiten, das möglicherweise Änderungen an benutzerdefinierten Zod-Schemas in deinem Projekt erforderlich macht.

Was soll ich tun?

Wenn du benutzerdefinierte Zod-Schemas in deiner content.config.ts oder anderen Konfigurationsdateien hast, musst du diese für Zod 4 aktualisieren. Ausführliche Informationen zu den Änderungen an der Zod-API findest du im Zod-Migrationsleitfaden.

Insbesondere sind viele string()-Formate veraltet (z. B. z.string().email(), z.string.url()), und ihre APIs wurden in den obersten z-Namensraum verschoben. Möglicherweise musst du die Art und Weise aktualisieren, wie du Formulareingaben für deine Astro Actions validierst:

src/actions/index.ts

email: z.string().email(),
email: z.email(),

Außerdem hat Zod einige Änderungen an der Behandlung von Fehlermeldungen vorgenommen und die Unterstützung für eine benutzerdefinierte errorsMap eingestellt, die nützlich war, um deine Fehlermeldungen neu zu definieren oder zu übersetzen. Möglicherweise musst du alle benutzerdefinierten Fehlermeldungen aktualisieren:

src/actions/index.ts

z.string().min(5, { message: "Zu kurz." });
z.string().min(5, { error: "Zu kurz." });

Wenn du .default() mit Transformationen verwendest, musst du möglicherweise deine Schemata aktualisieren. In Zod 4 müssen Standardwerte mit dem Ausgabetyp (nach den Transformationen) übereinstimmen, nicht mit dem Eingabetyp. Der Standardwert unterbricht die Analyse, wenn die Eingabe undefined ist:

src/content.config.ts

import { z } from 'astro/zod';

const blog = defineCollection({
  schema: z.object({
    // Zod 3: Standardmäßig angepasster Eingabetyp (Zeichenkette)
    views: z.string().transform(Number).default("0"),
    // Zod 4: Der Standardwert muss mit dem Ausgabetyp (Zahl) übereinstimmen
    views: z.string().transform(Number).default(0),
  })
});

Um das bisherige Verhalten zu nutzen, bei dem Standardwerte ausgewertet werden, verwende die neue Methode .prefault().

Dies sind nur einige der vielen Änderungen, die das Upgrade von Zod 3 auf Zod 4 mit sich bringt. Sollten nach dem Upgrade auf Astro 6 Probleme mit deinen Zod-Schemas auftreten, findest du im Zod 4-Changelog eine vollständige Anleitung zum Upgrade.

Außerdem steht ein Community-Codemod zur Verfügung, der bei der Migration von Zod 3 auf Zod 4 möglicherweise einige dieser Änderungen automatisieren kann.

Du kannst sicherstellen, dass du dieselbe Version von Zod verwendest, die Astro intern nutzt, indem du Zod aus astro/zod importierst.

import { z } from 'astro/zod';

Mehr Infos zum Modul astro/zod (EN).

Shiki 4.0

Implementierungs-PR: chore(deps): update shiki to v4 (#15726)

Astro v6.0 wechselt für die Syntaxhervorhebung zu Shiki v4.0.

Was soll ich tun?

Wenn du Shiki-spezifische APIs verwendest, schau dir den Shiki-Migrationsleitfaden an, um dich über Inkompatibilitäten zu informieren, und passe dein Projekt gegebenenfalls an.

Offizielle Astro-Integrationen

Alle offiziellen Server-Adapter von Astro (EN) wurden ebenfalls auf eine neue Hauptversion aktualisiert, um das Upgrade auf Vite v7.0 zu begleiten, wobei die Environment-API von Vite als Entwicklungsserver und Produktions-Bundler zum Einsatz kommt.

Insbesondere der Cloudflare-Adapter von Astro hat erhebliche Änderungen erfahren, und es ist mit Kompatibilitätsproblemen bei deiner bestehenden Cloudflare-Konfiguration zu rechnen.

Ausführliche Anweisungen zur Migration findest du in der Anleitung zum Upgrade des Cloudflare-Adapters (EN).

Was soll ich tun?

Wenn du einen Astro-Adapter für On-Demand-Rendering oder andere plattformspezifische Funktionen verwendest, lies bitte das Changelog deines jeweiligen Adapters, um Hinweise zum Upgrade zu erhalten:

• @astrojs/cloudflare-Changelog
• @astrojs/netlify-Changelog
• @astrojs/node-Changelog
• @astrojs/vercel-Changelog

Legacy

Die folgenden Funktionen gelten nun als Legacy-Funktionen. Sie sollten zwar weiterhin normal funktionieren, werden jedoch nicht mehr empfohlen und befinden sich im Wartungsmodus. Es sind keine weiteren Verbesserungen geplant, und die Dokumentation wird nicht mehr aktualisiert. Diese Funktionen werden irgendwann als veraltet eingestuft und anschließend vollständig entfernt.

Legacy: Rückwärtskompatibilität bei Content-Collections

In Astro 5.x konnten Projekte das Upgrade auf die neue Content-Layer-API, die für Content-Collections (Inhaltssammlungen) eingeführt wurde, hinauszögern, da eine gewisse automatische Abwärtskompatibilität bestand, die zuvor nicht hinter einem Flag verborgen war. Das bedeutete, dass ein Upgrade von Astro 4 auf Astro 5 möglich war, ohne deine Content-Collections zu aktualisieren, selbst wenn du das Flag legacy.collections nicht aktiviert hattest. Die Projekte ließen sich weiterhin erstellen, und es wurden keine Fehler oder Warnungen angezeigt.

Astro v6.0 entfernt diese automatische Unterstützung für ältere Content-Collections sowie das Flag legacy.collections. Alle Content-Collections müssen nun die in Astro v5.0 eingeführte Content-Layer-API nutzen, auf der alle Content-Collections basieren.

Was soll ich tun?

Sollten nach dem Update auf Version 6 Fehler bei den Inhaltssammlungen auftreten, überprüfe dein Projekt auf entfernte veraltete Funktionen, die möglicherweise auf die Content Layer API aktualisiert werden müssen.

Ausführliche Anweisungen zum Upgrade von älteren Collections auf die neue Content Layer API findest du im Astro v5-Upgrade-Leitfaden (EN).

Falls du nicht sofort aktualisieren kannst, kannst du das Flag legacy.collectionsBackwardsCompat (EN) als vorübergehende Migrationshilfe aktivieren:

astro.config.mjs

export default defineConfig({
  legacy: {
    collectionsBackwardsCompat: true,
  },
});

Dieser Flag bewahrt einige ältere Funktionen der Content-Collections aus Version 4:

• Unterstützt die alte Konfigurationsdatei src/content/config.ts
• Unterstützt type: 'content' und type: 'data' ohne Loader
• Behält die alte Entry-API bei: entry.slug und entry.render()
• Verwendet pfadbasierte Entry-IDs anstelle von slugbasierten IDs

Dies ist eine vorübergehende Migrationshilfe. Migriere deine Content-Collections so bald wie möglich zur Content Layer API und deaktiviere dieses Flag anschließend.

Veraltet

Die folgenden veralteten Funktionen werden nicht mehr unterstützt und sind nicht mehr dokumentiert. Bitte passe dein Projekt entsprechend an.

Einige veraltete Funktionen funktionieren möglicherweise vorübergehend weiter, bis sie vollständig entfernt werden. Andere haben möglicherweise stillschweigend keine Wirkung oder lösen einen Fehler aus, der dich dazu auffordert, deinen Code zu aktualisieren.

Veraltet: Astro in getStaticPaths()

Implementierungs-PR: feat: deprecate Astro in getStaticPaths (#14432)

In Astro 5.x war es möglich, innerhalb von getStaticPaths() auf ein Astro-Objekt zuzugreifen. Obwohl dieses Objekt denselben Typ hatte wie das im Frontmatter verfügbare Astro-Objekt, verfügte es jedoch nur über die Eigenschaften site und generator. Dies konnte zu Verwirrung darüber führen, welche Eigenschaften des Astro-Objekts innerhalb von getStaticPaths() verfügbar waren.

In Astro 6.0 wird dieses Objekt für getStaticPaths() als veraltet markiert, um Verwirrung zu vermeiden, und die Fehlerbehandlung beim Versuch, auf nicht verfügbare Astro-Werte zuzugreifen, wird verbessert. Die Verwendung von Astro.site oder Astro.generator innerhalb von getStaticPaths() führt nun zu einer Warnung wegen Veralterung, und der Zugriff auf jede andere Eigenschaft löst einen spezifischen Fehler mit einer hilfreichen Meldung aus. In einer zukünftigen Hauptversion wird dieses Objekt vollständig entfernt, und der Zugriff auf Astro.site oder Astro.generator löst ebenfalls einen Fehler aus.

Was soll ich tun?

Aktualisiere deine Funktion getStaticPaths(), falls du versucht hast, innerhalb ihres Geltungsbereichs auf Astro-Eigenschaften zuzugreifen. Entferne Astro.generator vollständig und ersetze alle Vorkommen von Astro.site durch import.meta.env.SITE:

src/pages/blog/[slug].astro

---
import { getPages } from "../../../utils/data";

export async function getStaticPaths() {
  console.log(Astro.generator);
  return getPages(Astro.site);
  return getPages(import.meta.env.SITE);
}
---

Erfahre mehr über integrierte Umgebungsvariablen wie import.meta.env.SITE (EN), auf die du zugreifen kannst, wenn du mit getStaticPaths() statische Routen dynamisch generierst (EN).

Veraltet: import.meta.env.ASSETS_PREFIX

Implementierungs-PR: feat: deprecate import.meta.env.ASSETS_PREFIX (#14461)

In Astro 5.x war es möglich, über die integrierte Umgebungsvariable import.meta.env.ASSETS_PREFIX auf build.assetsPrefix in deiner Astro-Konfiguration zuzugreifen. Mit Astro v5.7.0 wurde jedoch das virtuelle Modul astro:config eingeführt, um eine nicht erschöpfende, serialisierbare und typsichere Version der Astro-Konfiguration bereitzustellen, die direkten Zugriff auf build.assetsPrefix ermöglichte. Dies wurde zur bevorzugten Methode, um auf das Präfix für von Astro generierte Asset-Links zuzugreifen, sofern es gesetzt war, obwohl die Umgebungsvariable weiterhin existierte.

In Astro 6.0 wird diese Variable zugunsten von build.assetsPrefix aus dem Modul astro:config/server nicht mehr unterstützt.

Was soll ich tun?

Ersetze alle Vorkommen von import.meta.env.ASSETS_PREFIX durch den Import build.assetsPrefix aus astro:config/server. Dies ist ein direkter Ersatz, der den bestehenden Wert bereitstellt, und es sollten keine weiteren Änderungen an deinem Code erforderlich sein:

import { someLogic } from "./utils"
import { build } from "astro:config/server"

someLogic(import.meta.env.ASSETS_PREFIX)
someLogic(build.assetsPrefix)

Erfahre mehr über das virtuelle Modul astro:config (EN).

Veraltet: astro:schema und z aus astro:content

Implementierungs-PR: feat!: consolidate zod export (#14923)

In Astro 5.x wurde astro:schema als Alias für astro/zod eingeführt. Aus Gründen der Benutzerfreundlichkeit wurde z zudem aus astro:content exportiert. Dies führte jedoch gelegentlich zu Verwirrung bei Benutzern, die sich nicht sicher waren, von wo aus sie importieren sollten.

In Astro 6.0 werden astro:schema und z aus astro:content zugunsten von astro/zod als veraltet markiert.

Was soll ich tun?

Ersetze alle Vorkommen von astro:schema durch astro/zod:

import { z } from "astro:schema"
import { z } from "astro/zod"

Entferne z aus deinen astro:content-Importen und importiere z stattdessen separat aus astro/zod:

src/content.config.ts

import { defineCollection, z } from "astro:content"
import { defineCollection } from "astro:content"
import { z } from "astro/zod"

Mehr dazu unter Definieren von Collections-Schemata mit Zod (EN).

Veraltet: Interne Funktionen von astro:transitions sind nun öffentlich zugänglich

Implementierungs-PR: feat!: deprecate transitions exports (#14989)

In Astro 5.x wurden einige interne Komponenten aus astro:transitions und astro:transitions/client exportiert, die eigentlich nicht für die öffentliche Nutzung vorgesehen waren.

Astro 6.0 entfernt die folgenden Funktionen und Typen als Exporte aus den virtuellen Modulen astro:transitions und astro:transitions/client. Diese können nicht mehr in deine Projektdateien importiert werden:

• createAnimationScope()
• isTransitionBeforePreparationEvent()
• isTransitionBeforeSwapEvent()
• TRANSITION_BEFORE_PREPARATION
• TRANSITION_AFTER_PREPARATION
• TRANSITION_BEFORE_SWAP
• TRANSITION_AFTER_SWAP
• TRANSITION_PAGE_LOAD

Was soll ich tun?

Entferne alle Aufrufe von createAnimationScope():

import { createAnimationScope } from 'astro:transitions';

Aktualisiere alle Vorkommen der anderen veralteten Exporte:

import {
  isTransitionBeforePreparationEvent,
  TRANSITION_AFTER_SWAP,
} from 'astro:transitions/client';

console.log(isTransitionBeforePreparationEvent(event));
console.log(event.type === 'astro:before-preparation');

console.log(TRANSITION_AFTER_SWAP);
console.log('astro:after-swap');

Erfahre mehr über alle verfügbaren Funktionen in der Transitions Router API-Referenz (EN).

Veraltet: Signatur der Session-Treiber-Zeichenkette

Implementierungs-PR: feat(sessions): drivers (#15006)

In Astro 5.x konnte zur Definition eines Session-Treibers ein beliebiger Name eines Speicheranbieters oder ein benutzerdefinierter Einstiegspunkt angegeben werden, und Optionen konnten auch direkt in der session-Konfiguration festgelegt werden. Wir waren jedoch der Meinung, dass diese API eingeschränkt war und nicht mit anderen Teilen der Astro-Konfiguration übereinstimmte.

Astro 6.0 macht die Treiber-String-Signatur und die Optionen zugunsten einer neuen Objektform veraltet.

Was soll ich tun?

Aktualisiere deine Sitzungskonfiguration, um die neu exportierten sessionDrivers zu verwenden:

astro.config.mjs

import { defineConfig } from 'astro/config'
import { defineConfig, sessionDrivers } from 'astro/config'

export default defineConfig({
  session: {
    driver: 'redis',
    options: {
      url: process.env.REDIS_URL
    },
    driver: sessionDrivers.redis({
      url: process.env.REDIS_URL
    }),
    cookie: {
      secure: true
    },
    ttl: 3600
  }
})

Erfahre mehr über verfügbare Session-Treiber (EN).

Veraltet: NodeApp aus astro/app/node (Adapter-API)

Implementierungs-PR: feat: deprecate NodeApp (#15535)

In Astro 5.x konnten Adapter ihren Server-Einstiegspunkt mithilfe von App für Standard-Webanfragen/-antworten oder mithilfe von NodeApp für Node-Anfragen/-antworten implementieren.

In Astro 6.0 wird NodeApp zugunsten von createApp() und den neuen Hilfsfunktionen createRequest() und writeResponse() als veraltet markiert. Dies ermöglicht eine einheitlichere API, wobei die bisherigen Funktionen beibehalten werden. Außerdem wird der Typ NodeAppHeadersJson als veraltet markiert.

Was soll ich tun?

Wenn du einen Adapter erstellt hast, ersetze alle Verwendungen von NodeApp durch createApp():

mein-adapter/server.js

import { NodeApp } from 'astro/app/node';

export function createExports(manifest) {
  const app = new NodeApp(manifest);

  const handler = async (req, res) => {
    const response = await app.render(req);
    await NodeApp.writeResponse(response, res);
  };

  return { handler };
}
import { createApp } from 'astro/app/entrypoint';
import { createRequest, writeResponse } from 'astro/app/node';

const app = createApp();

export const handler = async (req, res) => {
  const request = createRequest(req);
  const response = await app.render(request);
  await writeResponse(response, res);
}

Erfahre mehr über das Modul astro/app/node (EN).

Veraltet: loadManifest() und loadApp() aus astro/app/node (Adapter-API)

Implementierungs-PR: feat: deprecate NodeApp (#15535)

In Astro 5.x stellte astro/app/node die Hilfsfunktionen loadManifest() und loadApp() bereit, um das Laden des SSR-Manifests oder einer NodeApp-Instanz aus einer URL-Instanz zu ermöglichen. Diese waren jedoch nicht dokumentiert und werden bei der v6-Adapter-API nicht mehr empfohlen.

In Astro 6.0 sind beide Funktionen veraltet.

Was soll ich tun?

Wenn du einen Adapter erstellt hast, entferne loadManifest() und ersetze loadApp() durch createApp():

mein-adapter/server.js

import { loadManifest, loadApp, NodeApp } from 'astro/app/node';

const manifest = await loadManifest(new URL(import.meta.url));
const app1 = new NodeApp(loadManifest);
const app2 = await loadApp(new URL(import.meta.url));
import { createApp } from 'astro/app/entrypoint';

const app = createApp();

Erfahre mehr über das Modul astro/app/entrypoint (EN).

Veraltet: createExports() und start() (Adapter-API)

Implementierungs-PR: feat: improve naming of new adapter api (#15461)

In Astro 5.x mussten Adapter die vom Host benötigten Exporte in ihrem Server-Einstiegspunkt mithilfe der Funktion createExports() bereitstellen, bevor sie diese als exports-Liste an setAdapter() übergeben wurden.

Astro 6.0 bietet eine einfachere und zugleich leistungsfähigere Methode zur Erstellung von Server-Einstiegspunkten. Dazu musst du die neue Option entrypointResolution: "auto" an setAdapter() übergeben.

Aus Gründen der Abwärtskompatibilität mit bestehenden Adaptern ahmt der Standardwert von entrypointResolution ("explicit") jedoch das Verhalten der Astro 5.x-API nach. Das bedeutet, dass deine Adapter weiterhin funktionieren, bis du deinen Adapter vollständig auf den Wert auto umstellen kannst, wie unten gezeigt.

Beachte, dass entrypointResolution: "explicit" (Beibehaltung des Verhaltens der v5-API) als veraltete Verwendung gilt; die Option wurde jedoch bereitgestellt, damit keine sofortige Änderung an deinem Adapter erforderlich ist und den Adapter-Entwicklern Zeit für die Aktualisierung bleibt. Diese Option wird in einer zukünftigen Hauptversion entfernt, damit alle Adapter entrypointResolution: "auto" verwenden.

Was soll ich tun?

Wenn du ein Adapter-Autor mit einem öffentlichen Repository bist und das Schlüsselwort astro-adapter in deine package.json einfügst (EN), wird das Astro-Core-Team versuchen, direkt einen PR an dein Repository zu senden, um dir bei der Migration deines Codes zu helfen, falls du die folgenden Schritte noch nicht befolgt hast.

Falls du Warnmeldungen erhältst, weil du einen Community-Adapter verwendest, der noch nicht aktualisiert wurde, wende dich bitte direkt an den Autor des Adapters, um ihn darauf hinzuweisen. Letztendlich liegt es in seiner Verantwortung, seine Adapter zu aktualisieren. Du kannst auch das Astro-Core im #integrations-Kanal unseres Discord-Servers darüber informieren, und wir werden versuchen, dem Adapter-Autor bei der Aktualisierung zu helfen.

Wenn du einen Adapter erstellt hast, befolge diese Schritte, um das alte v5-Verhalten zu entfernen:

1. Aktualisiere deine setAdapter()-Methode: Setze entrypointResolution: "auto", entferne exports und args

   mein-adapter.mjs

   setAdapter({
     // ...
     entrypointResolution: 'auto',
     exports: ['handler'],
     args: { assets: config.build.assets }
   })

2. Aktualisiere deinen Server-Einstiegspunkt, um alle erforderlichen Exporte ohne createExports() bereitzustellen:

   mein-adapter/server.js

   import { App } from 'astro/app';
   
   export function createExports(manifest) {
     const app = new App(manifest);
   
     const handler = (event, context) => {
       // ...
     };
   
     return { handler };
   }
   import { createApp } from 'astro/app/entrypoint';
   
   const app = createApp();
   
   export const handler = (event, context) => {
     // ...
   }

3. Wenn dein Adapter eine start()-Funktion bereitstellt, passe deinen Server-Einstiegspunkt so an, dass der Code direkt aufgerufen wird:

   mein-adapter/server.js

   import { App } from 'astro/app';
   
   export function start(manifest) {
     const app = new App(manifest);
   
     addEventListener('fetch', event => {
       // ...
     });
   }
   import { createApp } from 'astro/app/entrypoint';
   
   const app = createApp();
   
   addEventListener('fetch', event => {
     // ...
   });

4. Wenn du dich auf args verlassen hast, erstelle ein virtuelles Modul, um die Konfiguration zur Erstellungszeit zu übergeben (EN) und importiere sie stattdessen aus dem virtuellen Modul:

   mein-adapter/server.js

   export function createExports(manifest, { assets }) {
     // ...
   }
   import { assets } from 'virtual:@example/mein-adapter:config';

Erfahre mehr über die Adapter-API (EN).

Entfernt

Die folgenden Funktionen wurden nun vollständig aus dem Code entfernt und können nicht mehr verwendet werden. Einige dieser Funktionen haben in deinem Projekt möglicherweise auch nach ihrer Veralterung noch funktioniert. Andere haben möglicherweise stillschweigend keine Wirkung mehr gezeigt.

Projekte, die diese entfernten Funktionen noch enthalten, lassen sich nicht mehr kompilieren, und es gibt keine Dokumentation mehr, die dich dazu auffordert, diese Funktionen zu entfernen.

Entfernt: Legacy Content-Collections

Implementierungs-PR: fix: remove legacy content collections (#14407)

In Astro 5.x war es noch möglich, die ursprüngliche Content-Collections-API, die erstmals in Astro v2.0 eingeführt wurde, entweder über ein legacy-Konfigurationsflag oder über die integrierte Abwärtskompatibilität zu nutzen. Diese Methoden ermöglichten es dir, auf Astro v5 zu aktualisieren, auch wenn du noch nicht bereit oder in der Lage warst, deine bestehenden Content-Collections auf die neue Content Layer API umzustellen.

Astro v6.0 entfernt die Unterstützung für die bisher veraltete Content-Collections-API vollständig, einschließlich des Flags legacy.collections und einiger bestehender Abwärtskompatibilitäts­funktionen, die zuvor nicht hinter einem Flag verborgen waren. Alle Content-Collections müssen nun die in Astro v5.0 eingeführte Content Layer API verwenden, auf der alle Content-Collections basieren. Es gibt keine Unterstützung für Abwärtskompatibilität.

Was soll ich tun?

Falls du zuvor das Legacy-Flag aktiviert hast, musst du es deaktivieren.

astro.config.mjs

import { defineConfig } from 'astro/config';

export default defineConfig({
  legacy: {
    collections: true,
  }
})

Falls du deine Collections noch nicht auf Astro v5.0 aktualisiert hast, stelle außerdem sicher, dass deine Content-Collections für die neue API vollständig aktualisiert sind.

Astro v5.x bot eine gewisse automatische Abwärtskompatibilität, damit Content-Collections auch dann weiterhin funktionierten, wenn sie nicht auf die neue API aktualisiert worden waren. Daher können deine v5-Collections eine oder mehrere ältere Funktionen enthalten, die für v6 auf die neuere API aktualisiert werden müssen, selbst wenn dein Projekt zuvor fehlerfrei war.

Wenn nach dem Upgrade auf Version 6 Fehler oder Warnungen im Zusammenhang mit Content-Collections (EN) auftreten, kannst du anhand der folgenden Liste feststellen, ob in deinem Code noch veraltete Funktionen vorhanden sind, und diese aktualisieren.

Falls du …

keine Konfigurationsdatei für Content-Collections hast

Erstelle die Datei src/content.config.ts und definiere deine Collections (EN) darin.

eine Konfigurationsdatei unter src/content/config.ts hast / (LegacyContentConfigError (EN))

Benenne diese Datei um und verschiebe sie nach src/content.config.ts

eine Collection hast, für die kein loader definiert ist (ContentCollectionMissingALoaderError (EN))

Importiere Astros integrierten glob()-Loader (EN) und definiere pattern und base für deine Collection-Einträge:

src/content.config.ts

import { defineCollection } from 'astro:content';
import { z } from 'astro/zod';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/[^_]*.{md,mdx}', base: "./src/data/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
  }),
});

eine Collection hast, die einen Collection-Typ definiert (type: 'content' oder type: 'data') / (ContentCollectionInvalidTypeError (EN))

Es gibt keine verschiedenen Arten von Collections mehr. Dies muss aus deiner Collections-Definition gelöscht werden.

src/content.config.ts

import { defineCollection } from 'astro:content';
import { z } from 'astro/zod';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  // Für den Content Layer definierst du keinen `type` mehr
  type: 'content',
  loader: glob({ pattern: '**/[^_]*.{md,mdx}', base: "./src/data/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    pubDate: z.coerce.date(),
    updatedDate: z.coerce.date().optional(),
  }),
});

die veralteten Abfragemethoden für Collections getDataEntryById() und getEntryBySlug() verwendest / (GetEntryDeprecationError (EN))

Ersetze beide Methoden durch getEntry() (EN).

ältere Methoden zum Abfragen und Darstellen von Collections hast, die von einer slug-Eigenschaft abhängen / (ContentSchemaContainsSlugError (EN))

Bisher basierte die id auf dem Dateinamen, und es gab eine slug-Eigenschaft, die in einer URL verwendet werden konnte. Jetzt ist die id des CollectionEntry (EN) ein Slug. Wenn du Zugriff auf den Dateinamen benötigst (der zuvor als id verfügbar war), verwende die filePath-Eigenschaft. Ersetze alle Vorkommen von slug durch id:

src/pages/[slug].astro

---
export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.slug },
    params: { slug: post.id },
    props: post,
  }));
}
---

Inhalte hast, die mit entry.render() gerendert wurden

Collection-Einträge verfügen nicht mehr über eine render()-Methode. Importiere stattdessen die Funktion render() aus astro:content und verwende render(entry):

src/pages/index.astro

---
import { getEntry, render } from 'astro:content';

const post = await getEntry('pages', 'homepage');

const { Content, headings } = await post.render();
const { Content, headings } = await render(post);
---
<Content />

Weitere Informationen zur Abwärtskompatibilität von älteren Collections in Astro v5 sowie eine vollständige Schritt-für-Schritt-Anleitung für das Upgrade älterer Collections auf die neue Content Layer API findest du im Astro v5-Upgrade-Leitfaden (EN).

Entfernt: <ViewTransitions />-Komponente

Implementierungs-PR: Remove deprecated ViewTransitions component (#14400)

In Astro 5.0 wurde die Komponente <ViewTransitions /> in <ClientRouter /> umbenannt, um die Rolle der Komponente zu verdeutlichen. Der neue Name macht deutlicher, dass sich die Funktionen der Astro-Routing-Komponente <ClientRouter /> leicht von denen des nativen CSS-basierten MPA-Routers unterscheiden. Eine veraltete Version der Komponente <ViewTransitions /> existierte jedoch weiterhin und funktionierte möglicherweise auch in Astro 5.x.

Astro 6.0 entfernt die Komponente <ViewTransitions /> vollständig, sodass sie in deinem Projekt nicht mehr verwendet werden kann. Wechsle zur Komponente <ClientRouter />, um diese Funktionen weiterhin nutzen zu können.

Was soll ich tun?

Ersetze alle Vorkommen des Imports und der Komponente ViewTransitions durch ClientRouter:

src/layouts/MyLayout.astro

import { ViewTransitions } from 'astro:transitions';
import { ClientRouter } from 'astro:transitions';

<html>
  <head>
    ...
    <ViewTransitions />
    <ClientRouter />
  </head>
</html>

Erfahre mehr über View-Übergänge und clientseitiges Routing in Astro (EN).

Entfernt: emitESMImage()

Implementierungs-PR: feat!: remove emitESMImage() (#14426)

In Astro 5.6.2 wurde die Funktion emitESMImage() zugunsten von emitImageMetadata() als veraltet markiert. Dabei wurden zwei veraltete Argumente entfernt, die nicht für die öffentliche Nutzung vorgesehen waren: _watchMode und experimentalSvgEnabled.

Astro 6.0 entfernt emitESMImage() vollständig. Wechsle zu emitImageMetadata(), um das bisherige Verhalten beizubehalten.

Was soll ich tun?

Ersetze alle Vorkommen von emitESMImage() durch emitImageMetadata() und entferne nicht verwendete Argumente:

import { emitESMImage } from 'astro/assets/utils';
import { emitImageMetadata } from 'astro/assets/utils';

const imageId = '/images/photo.jpg';
const result = await emitESMImage(imageId, false, false);
const result = await emitImageMetadata(imageId);

Erfahre mehr über emitImageMetadata() (EN).

Entfernt: Astro.glob()

Implementierungs-PR: feat!: remove Astro.glob (#14421)

In Astro 5.0 wurde Astro.glob() als veraltet markiert; stattdessen solltest du nun getCollection() verwenden, um deine Sammlungen abzufragen, und import.meta.glob(), um andere Quelldateien in deinem Projekt abzufragen.

Astro 6.0 entfernt Astro.glob() vollständig. Aktualisiere auf import.meta.glob(), um das bisherige Verhalten beizubehalten.

Was soll ich tun?

Ersetze alle Verwendungen von Astro.glob() durch import.meta.glob(). Beachte, dass import.meta.glob() kein Promise mehr zurückgibt, sodass du deinen Code möglicherweise entsprechend anpassen musst. An deinen Glob-Mustern (EN) solltest du keine Änderungen vornehmen müssen.

src/pages/blog.astro

---
const posts = await Astro.glob('./posts/*.md');
const posts = Object.values(import.meta.glob('./posts/*.md', { eager: true }));
---

{posts.map((post) => <li><a href={post.url}>{post.frontmatter.title}</a></li>)}

Erwäge gegebenenfalls die Verwendung von Content-Collections (EN), um deine Inhalte zu organisieren. Diese verfügen über eigene, neuere und leistungsfähigere Abfragefunktionen.

Vielleicht möchtest du auch die Verwendung von Glob-Paketen aus npm in Betracht ziehen, wie zum Beispiel fast-glob.

Erfahre mehr über das Importieren von Dateien mit import.meta.glob (EN).

Entfernt: Interne Details von astro:actions

Implementierungs-PR: refactor: cleanup public actions API (#14844)

In Astro 5.x wurden einige interne Funktionen aus astro:actions exportiert, die eigentlich nicht für die öffentliche Nutzung vorgesehen waren.

Astro 6.0 entfernt die folgenden Funktionen, Klassen und Typen als Exporte aus dem virtuellen Modul astro:actions. Diese können nicht mehr in deine Projektdateien importiert werden:

• ACTION_ERROR_CODES
• ActionInputError
• appendForwardSlash
• astroCalledServerError
• callSafely
• deserializeActionResult
• formDataToObject
• getActionQueryString
• serializeActionResult
• type Actions
• type ActionAccept
• type AstroActionContext
• type SerializedActionResult

Was soll ich tun?

Ersetze alle Aufrufe von serializeActionResult() und deserializeActionResult() durch getActionContext(). Diese beiden Methoden sind nun über getActionContext() verfügbar:

src/middleware.ts

import { defineMiddleware } from 'astro:middleware';
import { serializeActionResult, deserializeActionResult } from 'astro:actions';
import { getActionContext } from 'astro:actions';

export const onRequest = defineMiddleware(async (context, next) => {
  const { serializeActionResult, deserializeActionResult } = getActionContext(context);
  // ...
});

Entferne alle Vorkommen der anderen entfernten Exporte:

import {
  ACTION_ERROR_CODES,
  ActionInputError,
  appendForwardSlash,
  astroCalledServerError,
  callSafely,
  formDataToObject,
  getActionQueryString,
  type Actions,
  type ActionAccept,
  type AstroActionContext,
  type SerializedActionResult,
} from 'astro:actions';

Erfahre mehr über alle verfügbaren Funktionen in der Actions-API-Referenz (EN).

Entfernt: Prozent-Kodierung in Routen

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x war es möglich, ein prozentkodiertes Prozentzeichen (%25) in Dateinamen zu verwenden.

Astro 6.0 hebt aus Sicherheitsgründen die Unterstützung für das Zeichen %25 in Dateinamen auf. Diese Einschränkung verhindert Sicherheitsumgehungen durch Kodierung, bei denen %25 in % umgewandelt wird, was möglicherweise zu mehrdeutigen oder ungültigen Kodierungssequenzen führen kann.

Was soll ich tun?

Wenn du Routendateien hast, deren Dateiname %25 enthält, benenne sie um, sodass ein anderes Zeichen verwendet wird:

src/pages/test%25file.astro
src/pages/test-file.astro

Entfernt: Virtuelles Modul astro:ssr-manifest (Integrations-API)

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x konnte das veraltete virtuelle Modul astro:ssr-manifest weiterhin zum Abrufen von Konfigurationswerten verwendet werden.

Astro 6.0 entfernt das virtuelle Modul astro:ssr-manifest vollständig. Es wird weder von Integrationen noch intern von Astro verwendet. Das Manifest wird nun direkt über Integrations-Hooks und Adapter-APIs übergeben, anstatt über ein virtuelles Modul. Für build-spezifische Manifestdaten verwende den Integrations-Hook astro:build:ssr, der das Manifest als Parameter erhält.

Was soll ich tun?

Wenn deine Integration oder dein Code aus astro:ssr-manifest importiert, verwende stattdessen astro:config/server, um auf Konfigurationswerte zuzugreifen:

import { manifest } from 'astro:ssr-manifest';
import { srcDir, outDir, root } from 'astro:config/server';
// Verwende srcDir, outDir, root usw. für Konfigurationswerte

Erfahre mehr über das virtuelle Modul astro:config (EN).

Entfernt: RouteData.generate() (Adapter-API)

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x konnten Routen mithilfe der Methode generate() von RouteData generiert werden.

Astro 6.0 entfernt RouteData.generate(), da die Routengenerierung nun intern von Astro übernommen wird.

Was soll ich tun?

Entferne alle Aufrufe von route.generate() aus deinem Code. Diese Methode wird nicht mehr benötigt:

const generated = route.generate(params);

Erfahre mehr über die Adapter-API (EN).

Entfernt: routes im Hook astro:build:done (Integrations-API)

Implementierungs-PR: feat: cleanup integration api (#14446)

In Astro 5.0 wurde der Zugriff auf routes im Hook astro:build:done als veraltet markiert.

Astro 6.0 entfernt das an diesen Hook übergebene routes-Array vollständig. Stattdessen sollte der Hook astro:routes:resolved verwendet werden.

Was soll ich tun?

Entferne alle Instanzen von routes, die an astro:build:done übergeben werden, und ersetze sie durch den neuen Hook astro:routes:resolved. Greife auf distURL in der neu bereitgestellten assets-Map zu:

meine-integration.mjs

const integration = () => {
    let routes
    return {
        name: 'meine-integration',
        hooks: {
            'astro:routes:resolved': (params) => {
                routes = params.routes
            },
            'astro:build:done': ({
                routes
                assets
            }) => {
                for (const route of routes) {
                    const distURL = assets.get(route.pattern)
                    if (distURL) {
                        Object.assign(route, { distURL })
                    }
                }
                console.log(routes)
            }
        }
    }
}

Erfahre mehr über den Integrations-API-Hook astro:routes:resolved (EN) zum Erstellen von Integrationen.

Entfernt: entryPoints im Hook astro:build:ssr (Integrations-API)

Implementierungs-PR: feat: cleanup integration api (#14446)

In Astro 5.0 wurde functionPerRoute als veraltet markiert (EN). Das bedeutete, dass entryPoints im Hook astro:build:ssr immer leer war.

Astro 6.0 entfernt die an diesen Hook übergebene entryPoints-Map vollständig.

Was soll ich tun?

Entferne alle Instanzen von entryPoints, die an astro:build:ssr übergeben werden:

meine-integration.mjs

const integration = () => {
    return {
        name: 'meine-integration',
        hooks: {
            'astro:build:ssr': (params) => {
                someLogic(params.entryPoints)
            },
        }
    }
}

Entfernt: alte Signatur von app.render() (Adapter-API)

Implementierungs-PR: feat: clean deprecated APIs (#14462)

In Astro 4.0 wurde die Signatur von app.render(), die die Übergabe von routeData und locals als optionale Argumente ermöglichte, zugunsten eines einzigen optionalen Arguments namens renderOptions als veraltet markiert.

Astro 6.0 entfernt diese Signatur vollständig. Der Versuch, diese separaten Argumente zu übergeben, führt nun zu einem Fehler in deinem Projekt.

Was soll ich tun?

Überprüfe deine app.render-Aufrufe und übergebe routeData und locals als Eigenschaften eines Objekts statt als mehrere separate Argumente:

mein-adapter/entrypoint.ts

app.render(request, routeData, locals)
app.render(request, { routeData, locals })

Erfahre mehr über die Adapter-API (EN).

Entfernt: app.setManifestData() (Adapter-API)

Implementierungs-PR: chore(astro)!: remove app.setManifestData() (#14758)

In Astro 5.0 war die Methode app.setManifestData() für App und NodeApp verfügbar, wird aber nicht mehr verwendet und ist auch nicht mehr erforderlich.

Astro 6.0 entfernt diese Methode komplett.

Was soll ich tun?

Entferne alle Aufrufe von app.setManifestData(). Wenn du das Manifest aktualisieren musst, erstelle eine neue App-Instanz.

Erfahre mehr über die Adapter-API (EN).

Entfernt: Die handleForms-Eigenschaft für die Komponente <ClientRouter />

Implementierungs-PR: feat: clean deprecated APIs (#14462)

In Astro 4.0 wurde die Eigenschaft handleForms der Komponente <ClientRouter /> als veraltet markiert, da es nicht mehr notwendig war, die Verarbeitung von submit-Events für form-Elemente aktiv zu aktivieren. Diese Funktionalität ist nun standardmäßig integriert, und die Eigenschaft hatte, falls sie noch in deinem Projekt enthalten war, keinerlei Auswirkungen auf das Absenden von Formularen.

Astro 6.0 entfernt diese Eigenschaft vollständig, und es muss nun entfernt werden, um Fehler in deinem Projekt zu vermeiden.

Was soll ich tun?

Entferne die Eigenschaft handleForms aus deiner Komponente <ClientRouter />, falls sie vorhanden ist. Sie hat keine zusätzlichen Funktionen bereitgestellt, daher sollte das Entfernen keine Auswirkungen auf das Verhalten deines Projekts haben:

src/pages/index.astro

---
import { ClientRouter } from "astro:transitions";
---
<html>
  <head>
    <ClientRouter handleForms />
  </head>
  <body>
    <!-- Kram hier -->
  </body>
</html>

Erfahre mehr über Übergänge mit Formularen (EN).

Entfernt: prefetch() mit der Option with

Implementierungs-PR: feat: clean deprecated APIs (#14462)

In Astro 4.8.4 wurde die Option with der programmatischen Funktion prefetch() als veraltet markiert, zugunsten eines sinnvolleren Standardverhaltens, bei dem die Priorität des Vorabrufens nicht mehr für jede Seite einzeln festgelegt werden muss.

Astro 6.0 hat diese Option komplett entfernt, und es ist nicht mehr möglich, die Priorität des Prefetching durch die Übergabe der Option with zu konfigurieren. Ein Versuch, dies zu tun, führt nun zu Fehlern.

Standardmäßig nutzt das Prefetching von Astro nun einen automatischen Ansatz, der immer versucht, <link rel="prefetch"> zu verwenden, sofern dies unterstützt wird, oder auf fetch() zurückgreift.

Was soll ich tun?

Überprüfe deine prefetch()-Aufrufe und entferne die Option with, falls sie noch vorhanden ist:

prefetch('/about', { with: 'fetch' });
prefetch('/about');

Erfahre mehr über Prefetching (EN).

Entfernt: rewrite() aus dem Actions-Kontext

Implementierungs-PR: feat!: remove rewrite from action context (#14477)

In Astro 5.5.6 wurde die Methode ActionAPIContext.rewrite als veraltet markiert, da anstelle von Umleitungen benutzerdefinierte Endpunkte verwendet werden sollten.

Astro 6.0 entfernt die Methode rewrite() vollständig aus ActionAPIContext, sodass sie nicht mehr verwendet werden darf.

Was soll ich tun?

Überprüfe deine Aktions-Handler und entferne alle Aufrufe von rewrite():

src/actions/index.ts

import { defineAction } from 'astro:actions';
import { z } from 'astro/zod';

export const server = {
  getGreeting: defineAction({
    input: z.object({
      // ...
    }),
    handler: async (input, context) => {
      context.rewrite('/')
      // ...
    }
  })
}

Erfahre mehr über Rewrites (EN).

Entfernt: Schema-Funktionssignatur (Content Loader API)

Implementierungs-PR: feat: loader.createSchema() (#14759)

In Astro 5.x konnte ein Content-Loader ein Schema als Funktion definieren, anstatt ein Zod-Schemaobjekt zur Validierung zu definieren. Das ist nützlich, um das Schema dynamisch basierend auf Konfigurationsoptionen oder durch Auswerten einer API zu generieren.

Astro 6.0 entfernt diese Signatur und führt die neue Eigenschaft createSchema() ein – als Ersatz für alle, die in ihrem Content-Loader weiterhin ein Schema dynamisch definieren möchten.

Wenn du eine Schema-Funktion auf die alte Art bereitstellst, wird eine Warnmeldung protokolliert, dass das Schema des Loaders ignoriert wird, aber ansonsten funktioniert der Loader weiterhin so, als wäre kein Schema angegeben worden. In einer zukünftigen Hauptversion werden Loader, die eine Schema-Funktion bereitstellen, einen Fehler auslösen und können nicht mehr verwendet werden.

Was soll ich tun?

Wenn du einen Content Loader entwickelst und eine Funktion verwendest, um eine schema-Eigenschaft der Collection dynamisch zurückzugeben, musst du deine bestehende Funktion entfernen und stattdessen die neue createSchema()-Eigenschaft verwenden, um dein Schema zu definieren.

Du kannst beispielsweise das bisherige Verhalten von Astro nachbilden, indem du zod-to-ts direkt mit createSchema() und deiner bisherigen Funktionslogik verwendest:

import type { Loader } from 'astro/loaders'
import { createTypeAlias, zodToTs } from 'zod-to-ts'
import { getSchemaFromApi } from './utils'

function myLoader() {
  return {
    name: 'mein-loader',
    load: async (context) => {
      // ...
    },
    schema: async () => await getSchemaFromApi(),
    createSchema: async () => {
      const schema = await getSchemaFromApi()
      const identifier = 'Entry'
      const { node } = zodToTs(schema, identifier)
      const typeAlias = createTypeAlias(node, identifier)

      return {
        schema,
        types: `export ${typeAlias}`
      }
    }
  } satisfies Loader
}

Erfahre mehr über createSchema() (EN) in der Content Loader-API-Referenz.

Entfernt: Session-Treiber test

Implementierungs-PR: feat(sessions): drivers (#15006)

In Astro 5.x wurde der interne Session-Treiber test in die Astro-Konfigurationstypen exportiert, war jedoch nicht für die öffentliche Nutzung vorgesehen.

In Astro 6.0 wurde der Session-Treiber test entfernt, da er intern nicht mehr zum Testen von context.session verwendet wird.

Was soll ich tun?

Es ist unwahrscheinlich, dass du diese interne API nutzt. Falls doch, musst du jegliche Verwendung des Session-Treibers test entfernen:

astro.config.mjs

import { defineConfig } from 'astro/config'
import { createMockStorage } from './utils'

export default defineConfig({
  session: {
    driver: 'test',
    options: {
      mockStorage: createMockStorage()
    }
  }
})

Erfahre mehr über die Session-Driver-API (EN).

Entfernt: Unterstützung für CommonJS-Konfigurationsdateien

Implementierungs-PR: Drop cjs config support (#15192)

In Astro 5.x konnte die Astro-Konfigurationsdatei eine der folgenden Dateiendungen haben: .mjs, .js, .ts, .mts, .cjs und .cts.

In Astro 6.0 werden die Dateiendungen .cjs und .cts entfernt.

Was soll ich tun?

Wenn du eine Datei namens astro.config.cjs oder astro.config.cts hast, passe sie so an, dass sie die unterstützten Dateiendungen verwendet: .mjs, .js, .ts oder .mts.

Erfahre mehr über die Astro-Konfigurationsdatei (EN).

Experimentelle Flags

Mit experimentellen Flags kannst du Funktionen aktivieren, die sich noch in einem frühen Entwicklungsstadium befinden. Astro nutzt experimentelle Flags möglicherweise auch, um grundlegende Änderungen am Standardverhalten zu testen. Die folgenden experimentellen Flags wurden in Astro 6.0 entfernt und sind nun stabil oder entsprechen dem neuen Standardverhalten.

Entferne diese experimentellen Flags aus deiner Astro-Konfiguration, falls du sie zuvor verwendet hast:

astro.config.mjs

import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    csp: true,
    fonts: true,
    liveContentCollections: true,
    preserveScriptOrder: true,
    staticImportMetaEnv: true,
    headingIdCompat: true,
    failOnPrerenderConflict: true
  },
})

Experimentelle Funktionen sind jetzt stabil:

• csp (Weitere Informationen zur Content Security Policy findest du in der Konfigurationsreferenz zu security.csp (EN).)
• fonts (Weitere Informationen zum Hinzufügen benutzerdefinierter Schriftarten zu deinem Projekt findest du im aktualisierten Leitfaden zu Schriftarten (EN).)
• liveContentCollections (Sieh dir die aktualisierte Dokumentation zu Content-Collections (EN), um mehr über Live-Collections zu erfahren.)
• failOnPrerenderConflict (Sieh dir die neue Konfigurationsoption prerenderConflictBehavior (EN).)

Neues Standard- oder empfohlenes Verhalten:

• preserveScriptOrder (Siehe unten für grundlegende Änderungen am Standardverhalten von <script> und <style>.)
• staticImportMetaEnv (Siehe unten für grundlegende Änderungen an import.meta.env.)
• headingIdCompat (Siehe unten für grundlegende Änderungen an der Generierung von Markdown-Überschriften-IDs.)

Erfahre mehr über spannende neue Funktionen und vieles mehr im Blogbeitrag zu Version 6.0.

Geänderte Standardeinstellungen

In Astro v6.0 haben sich einige Standardverhalten geändert, und dein Projektcode muss möglicherweise aktualisiert werden, um diesen Änderungen Rechnung zu tragen.

In den meisten Fällen musst du lediglich die Bereitstellung deines bestehenden Projekts überprüfen und sicherstellen, dass es weiterhin wie erwartet funktioniert, wobei du deinen Code bei Bedarf anpasst. In manchen Fällen gibt es möglicherweise eine Konfigurationseinstellung, mit der du das bisherige Standardverhalten weiterhin nutzen kannst.

Geändert: Standardwert von i18n.routing.redirectToDefaultLocale

Implementierungs-PR: feat(astro)!: update i18n.redirectToDefaultLocale default (#14406)

In Astro v5.0 war der Standardwert für i18n.routing.redirectToDefaultLocale auf true gesetzt. In Kombination mit dem Standardwert von false für i18n.routing.prefixDefaultLocale konnten die daraus resultierenden Weiterleitungen zu Endlosschleifen führen.

In Astro v6.0 ist i18n.routing.redirectToDefaultLocale nun standardmäßig auf false gesetzt. Außerdem kann es jetzt nur noch verwendet werden, wenn i18n.routing.prefixDefaultLocale auf true gesetzt ist.

Was soll ich tun?

Überprüfe deine Astro-i18n-Konfiguration, da du nun möglicherweise Werte für redirectToDefaultLocale und prefixDefaultLocale explizit festlegen musst, um das bisherige Verhalten deines Projekts wiederherzustellen.

astro.config.mjs

import { defineConfig } from 'astro/config';

export default defineConfig({
  i18n: {
    routing: {
      prefixDefaultLocale: true,
      redirectToDefaultLocale: true
    }
  }
})

Wenn du manuelles Routing verwendest, musst du möglicherweise auch deine Middleware-Konfiguration aktualisieren:

src/middleware.js

import { middleware } from "astro:i18n"; // Astros eigene Internationalisierungs-Routingkonfiguration

export const onRequest = middleware({
  prefixDefaultLocale: false,
  prefixDefaultLocale: true,
  redirectToDefaultLocale: true,
})

Erfahre mehr über Internationalisierungs-Routing (EN).

Geändert: <script>- und <style>-Tags werden in der Reihenfolge gerendert, in der sie definiert sind

Implementierungs-PR: feat: stabilize experimental preserveScriptOrder option (#14480)

In Astro v5.5 wurde das Flag experimental.preserveScriptOrder eingeführt, um mehrere <style>- und <script>-Tags in derselben Reihenfolge darzustellen, in der sie im Quellcode deklariert wurden. Astro 5.x kehrte ihre Reihenfolge in der generierten HTML-Ausgabe um. Dies konnte zu unerwarteten Ergebnissen führen, beispielsweise dazu, dass CSS-Styles beim Erstellen deiner Website durch früher definierte Style-Tags überschrieben wurden.

Astro 6.0 hebt dieses experimentelle Flag auf und macht dies zum neuen Standardverhalten in Astro: Skripte und Styles werden nun in der Reihenfolge gerendert, die in deinem Code definiert ist.

Was soll ich tun?

Falls du diese experimentelle Funktion bisher genutzt hast, musst du diesen experimentellen Flag aus deiner Konfiguration entfernen, da er nicht mehr existiert.

Überprüfe deine <script>- und <style>-Tags, um sicherzustellen, dass sie sich wie gewünscht verhalten. Möglicherweise musst du ihre Reihenfolge umkehren:

src/components/MyComponent.astro

<p>Ich bin eine Komponente</p>
<style>
  body {
    background: red;
    background: yellow;
  }
</style>
<style>
  body {
    background: yellow;
    background: red;
  }
</style>
<script>
    console.log("hallo")
    console.log("welt")
</script>
<script>
    console.log("welt!")
    console.log("hallo!")
</script>

Erfahre mehr über die Verwendung der Tags script (EN) und style (EN).

Geändert: Wie responsive Bild-Styles ausgegeben werden

Implementierungs-PR: support responsive images (#15407)

In Astro 5.x wurden Bilder zur Laufzeit berechnet, und die responsiven Bild-Styles fit und pos wurden in ein style-Attribut eingefügt. Dies war aus vielen Gründen nicht mit Astros Content Security Policy (CSP) kompatibel.

Astro 6 generiert Bild-Styles zur Erstellungszeit innerhalb eines virtuellen Moduls auf Basis der Projektkonfiguration, was zu einer Hash-Klasse und data-*-Attributen führt, mit denen du responsives Styling auf deine Bilder anwenden kannst.

Was soll ich tun?

Überprüfe deine Bilder visuell, um sicherzustellen, dass sie wie erwartet dargestellt werden. Dies ist ein Implementierungsdetail, das die erwartete Verwendung responsiver Bilder nicht beeinträchtigen sollte.

Falls du dich jedoch auf die zuvor für deine Bilder generierten Inline-Styles verlassen hast:

<img style="--fit: <value>; --pos: <value>" >

musst du deinen Projektcode anpassen, um stattdessen die neuen data-*-Attribute zu berücksichtigen:

<img class="__a_HaSh350" data-astro-fit="value" data-astro-pos="value" >

Inkompatible Änderungen

Die folgenden Änderungen gelten in Astro v6.0 als inkompatible Änderungen. Inkompatible Änderungen bieten unter Umständen vorübergehende Abwärtskompatibilität, unter Umständen aber auch nicht. Wenn du diese Funktionen genutzt hast, musst du deinen Code möglicherweise entsprechend den Empfehlungen in den einzelnen Einträgen anpassen.

Geändert: Endpunkte mit einer Dateiendung können nicht mit einem abschließenden Schrägstrich abgerufen werden

Implementierungs-PR: feat!: trailing slash never for endpoints with file extension (#14457)

In Astro v5.0 konnten benutzerdefinierte Endpunkte, deren URL mit einer Dateiendung endete (z. B. /src/pages/sitemap.xml.ts), sowohl mit einem abschließenden Schrägstrich (/sitemap.xml/) als auch ohne (/sitemap.xml) aufgerufen werden, unabhängig davon, welcher Wert für build.trailingSlash konfiguriert war.

In Astro v6.0 kann auf diese Endpunkte nur ohne abschließenden Schrägstrich zugegriffen werden. Dies gilt unabhängig von deiner Konfiguration für build.trailingSlash.

Was soll ich tun?

Überprüfe deine Links zu deinen benutzerdefinierten Endpunkten, die eine Dateiendung in der URL enthalten, und entferne alle abschließenden Schrägstriche:

src/pages/index.astro

<a href="/sitemap.xml/">Sitemap</a>
<a href="/sitemap.xml">Sitemap</a>

Erfahre mehr über benutzerdefinierte Endpunkte (EN).

Geändert: Die Werte in import.meta.env werden immer inline eingebunden

Implementierungs-PR: feat: stabilize static import meta env (#14485)

In Astro 5.13 wurde das Flag experimental.staticImportMetaEnv eingeführt, um das Verhalten beim direkten Zugriff auf import.meta.env anzupassen und es an Vites Handhabung von Umgebungsvariablen anzupassen. Dadurch wird sichergestellt, dass die Werte von import.meta.env immer inline eingebunden werden.

In Astro 5.x wurden nicht-öffentliche Umgebungsvariablen durch einen Verweis auf process.env ersetzt. Außerdem konnte Astro den Wertetyp deiner über import.meta.env verwendeten Umgebungsvariablen umwandeln, was den Zugriff auf bestimmte Werte verhindern konnte, wie zum Beispiel die Zeichenfolgen "true" (die in einen booleschen Wert umgewandelt wurde) und "1" (die in eine Zahl umgewandelt wurde).

Astro 6 hebt dieses experimentelle Flag auf und macht dies zum neuen Standardverhalten in Astro: Die Werte von import.meta.env werden immer inline eingefügt und niemals umgewandelt.

Was soll ich tun?

Falls du diese experimentelle Funktion bisher genutzt hast, musst du diesen experimentellen Flag aus deiner Konfiguration entfernen, da er nicht mehr existiert.

Falls du dich auf die automatische Typumwandlung verlassen hast, musst du deinen Projektcode möglicherweise anpassen, um sie manuell anzuwenden:

src/components/MyComponent.astro

const enabled: boolean = import.meta.env.ENABLED;
const enabled: boolean = import.meta.env.ENABLED === "true";

Falls du dich auf die Umwandlung in process.env verlassen hast, musst du deinen Projektcode möglicherweise anpassen, um dies manuell zu übernehmen:

src/components/MyComponent.astro

const enabled: boolean = import.meta.env.DB_PASSWORD;
const enabled: boolean = process.env.DB_PASSWORD;

Möglicherweise musst du auch die Typen aktualisieren:

src/env.d.ts

interface ImportMetaEnv {
  readonly PUBLIC_POKEAPI: string;
  readonly DB_PASSWORD: string;
  readonly ENABLED: boolean;
  readonly ENABLED: string;
}

interface ImportMeta {
  readonly env: ImportMetaEnv;
}

namespace NodeJS {
  interface ProcessEnv {
    DB_PASSWORD: string;
  }
}

Wenn du mehr Kontrolle über Umgebungsvariablen in Astro benötigst, empfehlen wir dir, astro:env zu verwenden.

Erfahre mehr über Umgebungsvariablen (EN) in Astro, einschließlich astro:env.

Geändert: Standardmäßiges Zuschneiden im Standard-Bilddienst

Implementierungs-PR: feat(assets): Always allow cropping and never upscale (#14629)

In Astro 5.0 hat der Standard-Bilddienst das Bild nur dann zugeschnitten, wenn die Option fit angegeben wurde.

Astro 6.0 wendet standardmäßig einen Bildausschnitt an, ohne dass die Option fit eingestellt werden muss.

Was soll ich tun?

An deinen bestehenden zugeschnittenen Bildern sind keine Änderungen erforderlich, da die Eigenschaft fit weiterhin gültig ist. Wenn du jedoch zuvor fit auf contain (den Standardwert) gesetzt hast, um deine Bilder zuzuschneiden, kannst du diese Option nun entfernen und dennoch dasselbe Zuschneideverhalten erzielen, indem du lediglich width und height angibst:

src/components/MyImage.astro

---
import { Image } from 'astro:assets';
import myImage from '../assets/photo.jpg';
---
<Image src={myImage} width={400} height={300} fit="contain" />
<Image src={myImage} width={400} height={300} />

Geändert: Bilder im Standard-Bilddienst niemals hochskalieren

Implementierungs-PR: feat(assets): Always allow cropping and never upscale (#14629)

In Astro 5.x hat der Standard-Bilddienst Bilder hochskaliert, wenn die angeforderten Abmessungen größer waren als die des Quellbildes.

Astro 6.0 behebt dieses Problem: Der Standard-Bilddienst skaliert Bilder nicht mehr hoch.

Was soll ich tun?

Überprüfe deine Bilder und passe die Abmessungen bei Bedarf an. Falls du Bilder vergrößern musst, kannst du dies entweder manuell tun oder einen Bildbearbeitungsdienst nutzen, der die Vergrößerung unterstützt.

Geändert: SVG-Rasterisierung

Implementierungs-PR: add support for SVG rasterization (#15180)

In Astro v5.x konnte der standardmäßige Sharp-Bilddienst von Astro keine SVG-Dateien in Rasterdateien (z. B. PNG, WebP) konvertieren. Das bedeutete, dass die Komponente <Image /> bei der Optimierung und Umwandlung von SVG-Dateien jeden für format festgelegten Wert ignorierte.

Astro 6.0 unterstützt jetzt die SVG-Rasterisierung. Dies unterliegt zahlreichen Einschränkungen; so werden beispielsweise SVGs mit eingebetteten Schriftarten möglicherweise nicht korrekt konvertiert. Wenn jedoch die Eigenschaft format gesetzt ist, versucht der Bilddienst nun, SVG-Bilder zu konvertieren.

Was soll ich tun?

Wenn du dich bisher darauf verlassen hast, dass der Bilddienst die Konvertierung von SVGs automatisch überspringt, musst du nun das Format deiner Bilder vorab überprüfen, um zu vermeiden, dass SVGs in Rasterbilder umgewandelt werden:

<Image src={imageThatMightBeAnSvg} format="avif" alt="example" />

<Image
  src={imageThatMightBeAnSvg}
  format={imageThatMightBeAnSvg.format === "svg" ? "svg" : "avif"}
  alt="example"
/>

Erfahre mehr über die Bild-Eigenschaft format (EN)

Geändert: getImage() löst einen Fehler aus, wenn es auf dem Client aufgerufen wird

Implementierungs-PR: feat: disallow getImage on the client (#15800)

In Astro 5.x schlug der Aufruf von getImage() aus astro:assets auf dem Client ohne Fehlermeldung fehl oder lieferte falsche Ergebnisse.

Astro 6.0 löst einen Laufzeitfehler aus, wenn getImage() auf dem Client aufgerufen wird.

Was soll ich tun?

Rufe stattdessen auf dem Server getImage() auf und übergib das resultierende src an den Client:

src/components/ClientImage.astro

---
import { getImage } from "astro:assets";
import myBackground from "../background.png";

const optimizedBackground = await getImage({ src: myBackground, format: "avif" });
---

<div id="background" data-src={optimizedBackground.src}></div>

<script>
  const src = document.getElementById("background").dataset.src;
  // Verwende src auf der Client-Seite nach Bedarf
</script>

Ein vollständiges Beispiel findest du unter Bilder mit getImage() generieren (EN).

Geändert: Generierung von Markdown-Überschriften-IDs

Implementierungs-PR: feat!: stabilize experimental.headingIdCompat (#14494)

In Astro 5.x entfernte ein zusätzlicher Standardverarbeitungsschritt bei der Markdown-Konvertierung abschließende Bindestriche am Ende von IDs für Abschnittsüberschriften, die mit Sonderzeichen endeten. Dies sorgte für einen übersichtlicheren id-Wert, konnte jedoch zu Inkompatibilitäten bei der plattformübergreifenden Darstellung deines Markdowns führen.

In Astro 5.5 wurde das Flag experimental.headingIdCompat eingeführt, damit du die von Astro generierten IDs für Markdown-Überschriften mithilfe des beliebten Pakets github-slugger mit gängigen Plattformen wie GitHub und npm kompatibel machen kannst.

Astro 6.0 hebt diese experimentelle Markierung auf und macht dies zum neuen Standardverhalten in Astro: Nachgestellte Bindestriche am Ende von IDs für Überschriften, die mit Sonderzeichen enden, werden nicht mehr entfernt.

Was soll ich tun?

Wenn du manuelle Links zu Überschriften hast, musst du möglicherweise den Wert des Ankerlinks um einen neuen abschließenden Bindestrich ergänzen. Zum Beispiel erzeugt die folgende Markdown-Überschrift

## `<Picture />`

nun den folgenden HTML-Code mit einem abschließenden Bindestrich in der Überschrift id

<h2 id="picture-"><code>&lt;Picture /&gt;</code></h2>

und muss nun wie folgt verlinkt werden:

Weitere Informationen findest du unter [der `<Picture />`-Komponente](/de/guides/images/#picture-).

Falls du bisher die experimentelle Funktion zur Erzwingung von abschließenden Bindestrichen genutzt hast, musst du dieses experimentelle Flag aus deiner Konfiguration entfernen, da es nicht mehr existiert.

Falls du bisher das Plugin rehypeHeadingIds direkt verwendet hast, um die Kompatibilität sicherzustellen, entferne die Option headingIdCompat, da sie nicht mehr existiert:

astro.config.mjs

import { defineConfig } from 'astro/config';
import { rehypeHeadingIds } from '@astrojs/markdown-remark';
import { otherPluginThatReliesOnHeadingIDs } from 'some/plugin/source';

export default defineConfig({
  markdown: {
    rehypePlugins: [
      [rehypeHeadingIds, { headingIdCompat: true }],
      [rehypeHeadingIds],
      otherPluginThatReliesOnHeadingIDs,
    ],
  },
});

Wenn du die alte ID-Generierung aus Gründen der Abwärtskompatibilität beibehalten möchtest, kannst du ein benutzerdefiniertes Rehype-Plugin erstellen, das Überschriften-IDs wie bei Astro 5.x generiert. So kannst du deine bestehenden Ankerlinks weiterhin verwenden, ohne abschließende Bindestriche hinzufügen zu müssen.

Erstelle ein benutzerdefiniertes Rehype-Plugin, um abschließende Bindestriche zu entfernen

1. Installiere die erforderlichen Abhängigkeiten:

   npm

   npm i github-slugger hast-util-heading-rank unist-util-visit hast-util-to-string

   pnpm

   pnpm add github-slugger hast-util-heading-rank unist-util-visit hast-util-to-string

   Yarn

   yarn add github-slugger hast-util-heading-rank unist-util-visit hast-util-to-string

2. Erstelle ein benutzerdefiniertes Rehype-Plugin, das Überschriften-IDs wie bei Astro v5 generiert:

   plugins/rehype-slug.mjs

   import GithubSlugger from 'github-slugger';
   import { headingRank } from 'hast-util-heading-rank';
   import { visit } from 'unist-util-visit';
   import { toString } from 'hast-util-to-string';
   
   const slugs = new GithubSlugger();
   
   export function rehypeSlug() {
     /**
      * @param {import('hast').Root} tree
      */
     return (tree) => {
       slugs.reset();
       visit(tree, 'element', (node) => {
         if (headingRank(node) && !node.properties.id) {
           let slug = slugs.slug(toString(node));
           // Entferne abschließende Bindestriche wie in Astro v5 und älter:
           if (slug.endsWith('-')) slug = slug.slice(0, -1);
           node.properties.id = slug;
         }
       });
     };
   }

3. Füge das benutzerdefinierte Plugin in deiner Markdown-Konfiguration in astro.config.mjs hinzu:

   astro.config.mjs

   import { defineConfig } from 'astro/config';
   import { rehypeSlug } from './plugins/rehype-slug';
   
   export default defineConfig({
     markdown: {
       rehypePlugins: [rehypeSlug],
     },
   });

Erfahre mehr über Überschriften-IDs (EN).

Geändert: getStaticPaths() darf keine params vom Typ number zurückgeben

Implementierungs-PR: fix!: disallow number in getStaticPaths params (#14586)

In Astro 5.x konnte getStaticPaths() params vom Typ number zurückgeben, die von Astro immer in eine Zeichenkette umgewandelt wurden. Das konnte jedoch verwirrend sein, da es zu Konflikten mit den Typen von Astro.params führte.

Astro 6.0 beseitigt dieses Verhalten: getStaticPaths() muss nun params-Werte vom Typ string oder undefined zurückgeben.

Was soll ich tun?

Überprüfe deine dynamischen Routen mit getStaticPaths() und wandle alle numerischen Parameter in Zeichenfolgen um:

src/pages/post/[id]/[label].astro

---
export function getStaticPaths() {
  return [
    {
      params: {
        id: 1,
        id: "1",
        label: "foo",
      }
    },
    {
      params: {
        id: 2,
        id: "2",
        label: "bar",
      }
    },
  ]
}
---

Erfahre mehr über dynamische SSG-Routen mit getStaticPaths() (EN).

Geändert: Astro-Komponenten können in Vitest-Client-Umgebungen nicht gerendert werden (Container-API)

Implementierungs-PR: feat: remove Vitest workaround for client environment (#14895)

In Astro 5.x war das Rendern einer Astro-Komponente auf dem Client untersagt. Wir haben dieses Verhalten jedoch vorübergehend in Vitest-Client-Umgebungen wie jsdom oder happy-dom mithilfe der experimentellen Container-API (EN) zugelassen.

Astro 6.0 hebt die Möglichkeit auf, Astro-Komponenten in Vitest-Client-Umgebungen darzustellen: Tests, die Astro-Komponenten darstellen, müssen nun in einer Serverumgebung wie node ausgeführt werden.

Was soll ich tun?

Wenn du Vitest nutzt, um Tests auszuführen, die Astro-Komponenten in Client-Umgebungen wie jsdom oder happy-dom rendern, passe deine Vitest-Konfiguration so an, dass hierfür die node-Umgebung verwendet wird:

vitest.config.ts

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environment: 'jsdom',
    environment: 'node',
  },
});

Erfahre mehr über das Testen von Astro-Komponenten (EN).

Geändert: Konfigurationspfad für den Dateinamen der Rollup-Ausgabedatei (Vite-Konfiguration)

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x konnten benutzerdefinierte Optionen für den Dateinamen der Rollup-Ausgabedatei für Client-Assets unter vite.build.rollupOptions.output konfiguriert werden.

Astro 6.0 passt die Konfiguration der Client-Build-Ausgabe an die Client-Umgebung von Vite an. Wenn du entryFileNames, chunkFileNames oder assetFileNames für Client-Assets anpasst, verwende vite.environments.client.build.rollupOptions.output.

Was soll ich tun?

Verschiebe deine Konfiguration von vite.build.rollupOptions.output nach vite.environments.client.build.rollupOptions.output:

astro.config.mjs

export default defineConfig({
  vite: {
    environments: {
      client: {
        build: {
          rollupOptions: {
            output: {
              entryFileNames: 'js/[name]-[hash].js',
            },
          },
        },
      },
    },
  },
});

Geändert: Integrations-Hooks und HMR-Zugriffsmuster (Integrations-API)

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x stützte sich Astro auf bestimmte Muster für Integrations-Hooks und den HMR-Zugriff, die mit der Environment-API von Vite nicht kompatibel waren oder durch deren Integration verbessert werden konnten.

Astro 6.0 nutzt die neue Environment-API von Vite für die Build-Konfiguration und die Interaktion mit dem Entwicklungsserver. Das ermöglicht vor allem den Entwicklungsmodus in Laufzeiten wie workerd, bedeutet aber auch, dass sich einige Integrations-Hooks und HMR-Zugriffsmuster geändert haben.

Was soll ich tun?

Für Integrationen, die astro:build:setup verwenden:

Der Hook wird nun einmalig mit allen konfigurierten Umgebungen (ssr, client, prerender) aufgerufen, anstatt für jedes Build-Ziel separat aufgerufen zu werden. Entferne den Parameter target und verwende vite.environments, um bestimmte Umgebungen zu konfigurieren:

meine-integration.mjs

{
  hooks: {
    'astro:build:setup': ({ target, vite }) => {
      if (target === 'client') {
        vite.build.minify = false;
      }
    }
    'astro:build:setup': ({ vite }) => {
      vite.environments.client.build.minify = false;
    }
  }
}

Für die Entwickler-Symbolleiste und den Integrationscode für den Zugriff auf HMR:

Ersetze server.hot.send() durch server.environments.client.hot.send():

server.hot.send(event)
server.environments.client.hot.send(event)

Erfahre mehr über die Vite-Environment-API und die Integrations-Hooks (EN) von Astro.

Geändert: Struktur der Schnittstelle SSRManifest (Adapter-API)

Implementierungs-PR: feat: integrate vite environments (#14306)

In Astro 5.x waren die Pfadeigenschaften der Schnittstelle SSRManifest wie srcDir, outDir, cacheDir, publicDir, buildClientDir und buildServerDir URL-Zeichenfolgen.

In Astro 6.0 werden diese Pfadeigenschaften nun als URL-Objekte statt als URL-Zeichenfolgen verwendet. Durch diese Änderung stehen im Manifest nun mehrere neue Eigenschaften zur Verfügung, während andere aktualisiert oder entfernt wurden.

Was soll ich tun?

Wenn du diese Pfadeigenschaften bisher als Zeichenfolgen behandelt hast, musst du nun mit dem URL-Objekt arbeiten. Du musst nun beispielsweise auf die Eigenschaft href des URL-Objekts zugreifen:

// Um dasselbe Format (z. B. "file:///pfad/zu/src") beizubehalten, nimm folgende Änderung vor:
const srcPath = manifest.srcDir;
const srcPath = manifest.srcDir.href;

Wenn du bisher auf die Eigenschaft hrefRoot zugegriffen hast, musst du sie entfernen, da sie im Manifest nicht mehr verfügbar ist.

Aktualisiere alle Verwendungen von serverIslandMappings und sessionDriver. Das sind jetzt asynchrone Methoden:

const mappings = manifest.serverIslandMappings;
const driver = manifest.sessionDriver;
const mappings = await manifest.serverIslandMappings?.();
const driver = await manifest.sessionDriver?.();

Erfahre mehr über die Adapter-API (EN).

Geändert: Schematypen werden abgeleitet statt generiert (Content Loader API)

Implementierungs-PR: feat: loader.createSchema() (#14759)

In Astro 5.x wurden die Typen für Inhaltssammlungen mithilfe von zod-to-ts generiert, wenn sie von einem Content Loader Inhaltslader bereitgestellt und nicht durch ein benutzerdefiniertes Schema festgelegt wurden.

In Astro 6.0 wurde dieses Verhalten entfernt: Typen werden nicht mehr mithilfe von zod-to-ts generiert. Stattdessen werden die Typen abgeleitet.

Was soll ich tun?

Wenn du in einem Content Loader ein Schema bereitstellst, musst du den TypeScript-Operator satisfies verwenden:

import type { Loader } from 'astro/loaders'

function myLoader(): Loader {
function myLoader() {
  return {
    name: 'meine-lader',
    load: async (context) => {
      // ...
    },
    schema: z.object({/* ... */})
  }
  } satisfies Loader
}

Erfahre mehr über die Definition von Loader-Schematypen (EN).

Bekannte Probleme

Schau bitte unter Astro-Issues auf GitHub nach gemeldeten Problemen oder um selbst ein Problem zu melden.