Zum Inhalt springen

Auf Astro v3 aktualisieren

Diese Anleitung hilft dir bei der Migration von Astro v2 zu Astro v3.

Du musst ein älteres Projekt auf v2 aktualisieren? Siehe unsere ältere Anleitung zur Migration.

Aktualisiere die Astro-Version deines Projekts mit deinem Paketmanager auf die neueste Version. Wenn du Astro-Integrationen verwendest, aktualisiere bitte auch diese auf die neueste Version.

Terminal-Fenster
# Upgrade auf Astro v3.x
npm install astro@latest
# Beispiel: React- und Tailwind-Integrationen aktualisieren
npm install @astrojs/react@latest @astrojs/tailwind@latest

Experimentelle Optionen von Astro v3.0 wurden entfernt

Abschnitt betitelt Experimentelle Optionen von Astro v3.0 wurden entfernt

Entferne die folgenden experimentellen Optionen aus astro.config.mjs:

astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
experimental: {
assets: true,
viewTransitions: true,
},
})

Diese Features sind jetzt standardmäßig verfügbar:

  • View Transitions für animierte Seitenübergänge und persistente Astro-Inseln. Siehe die Breaking Changes von der View Transitions API und Upgrade-Ratschläge (EN), wenn du diese experimentelle Option verwendet hast.
  • Eine neue Bildservices-API astro:assets für das Verwenden von Bildern in Astro, einschließlich einer neuen <Image />-Komponente und der getImage()-Funktion. Bitte lies den detaillierten Bilder Upgrade-Ratgeber (EN) unabhängig davon, ob du diese experimentelle Option verwendet hast, um zu sehen, wie sich dies auf dein Projekt auswirken könnte.

Lies mehr über diese zwei interessanten Features und mehr im Astro 3.0 Blogbeitrag!

Astro v3.0 enthält einige wichtige Änderungen und einige veraltete Features wurden entfernt. Wenn dein Projekt nach dem Upgrade auf v3.0 nicht mehr wie erwartet funktioniert, findest du in dieser Anleitung eine Übersicht über alle Änderungen und Anweisungen, wie du deine Codebasis aktualisieren kannst.

Siehe das Änderungsprotokoll für die vollständigen Versionshinweise.

Node 16 wird voraussichtlich im September 2023 sein Lebensende erreichen.

Astro v3.0 verzichtet komplett auf die Unterstützung von Node 16, damit alle Astro-Benutzer die Vorteile der moderneren Features von Node nutzen können.

Vergewissere dich, dass sowohl deine Entwicklungs- als auch deine Veröffentlichungs-Umgebung Node 18.14.1 oder höher verwenden.

  1. Überprüfe deine lokale Version von Node mit:

    Terminal-Fenster
    node -v
  2. Überprüfe die Dokumentation deiner Veröffentlichungs-Umgebung, um sicherzustellen, dass sie Node 18 unterstützt.

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

.nvmrc
18.14.1

Entfernt: Unterstützung für TypeScript 4

Abschnitt betitelt Entfernt: Unterstützung für TypeScript 4

Die tsconfig.json-Voreinstellungen in Astro v2.x unterstützen TypeScript 4.x und 5.x.

Astro v3.0 aktualisiert diese Voreinstellungen und geht jetzt davon aus, dass du TypeScript 5.0 (März 2023) verwendest, oder dass dein Editor diese Version einschließt (wie z.B. VS Code 1.77).

Falls du TypeScript lokal installiert hast, aktualisiere es mindestens auf v5.0.

Terminal-Fenster
npm install typescript@latest --save-dev

In Astro v2.x stellte Astro eine offizielle Bildintegration zur Verfügung, die Astro <Image />- und <Picture />-Komponenten einschloss.

Mit Astro v3.0 wurde diese Integration komplett entfernt. Die neue Lösung für den Umgang mit Bildern ist eine integrierte Bildservices-API: astro:assets.

Entferne die @astrojs/image-Integration aus deinem Projekt. Du musst nicht nur die Integration deinstallieren, sondern auch alle Import-Anweisungen sowie die vorhandenen <Image />- und <Picture />-Komponenten aktualisieren oder entfernen. Möglicherweise musst du auch einen bevorzugten Standardbildverarbeitungsdienst konfigurieren.

Du findest eine Schritt-für-Schritt-Anleitung zum Entfernen der alten Bildintegration (EN) in unserer Bilder-Anleitung.

Die Migration zu astro:assets bringt auch einige neue Bildoptionen und Features mit sich, die du vielleicht nutzen möchtest. Bitte sieh dir den vollständigen Upgrade-Ratgeber für Bilder in Version 3.0 (EN) für alle Details an!

astro.config.mjs
import { defineConfig } from 'astro/config';
import image from '@astrojs/image';
export default defineConfig({
integrations: [
image(),
]
})

In Astro v1.x wurde die <Markdown />-Komponente als veraltet deklariert und in ein externes Paket verschoben.

In Astro v3.0 wurde das Paket @astrojs/markdown-component vollständig entfernt. Die <Markdown />-Komponente von Astro wird nicht mehr in deinem Projekt funktionieren.

Entferne alle Verwendungen von @astrojs/markdown-component.

src/components/MyAstroComponent.astro
---
import Markdown from '@astrojs/markdown-component';
---

Um eine ähnliche <Markdown />-Komponente in deinem Code weiter zu verwenden, erwäge die Verwendung von Community-Integrationen wie astro-remote. Stelle sicher, dass du alle nötigen Änderungen an den Importen und Attributen deiner <Markdown />-Komponenten vornimmst, die in der Dokumentation der Integration angegeben sind.

Andernfalls entferne alle Importe der Astro-<Markdown />-Komponente sowie die Komponenten selbst aus deinen .astro-Dateien. Du musst deine Inhalte dann entweder in HTML umschreiben oder Markdown importieren, indem du .md-Dateien verwendest.

Mit Astro v1.x wurden unsere ursprünglichen Konfigurationseinstellungen sowie die Unterstützung von <style global> und <script hoist> als veraltet deklariert. Sie wurden jedoch weiterhin zur Abwärtskompatibilität unterstützt.

Astro v3.0 entfernt diese veralteten APIs vollständig. Stattdessen sollten die offiziell unterstützten Konfigurationseinstellungen (EN) und die moderne Syntax <style is:global> und <script> verwendet werden.

Wenn du weiterhin v1.x APIs verwendest, nutze stattdessen die neuen APIs für die jeweiligen Features:

Entfernt: Partielle Shims für Web-APIs in Server Code

Abschnitt betitelt Entfernt: Partielle Shims für Web-APIs in Server Code

In Astro v2.x hat Astro partielle Shims für Web-APIs wie document oder localStorage im serverseitig gerenderten Code bereitgestellt. Diese Shims waren oft unvollständig und unzuverlässig.

Astro v3.0 entfernt diese partiellen Shims vollständig. Web-APIs stehen nicht mehr im serverseitig gerenderten Code zur Verfügung.

Wenn du Web-APIs in serverseitig gerenderten Komponenten verwendest, musst du entweder die Verwendung dieser APIs bedingt machen oder client:only (EN) verwenden.

Entfernt: image aus astro:content im Schema von Inhalts-Sammlungen

Abschnitt betitelt Entfernt: image aus astro:content im Schema von Inhalts-Sammlungen

In Astro v2.x wurde der image-Export aus astro:content als veraltet deklariert, der für Schemas im Rahmen von Inhalts-Sammlungen verwendet wurde.

Astro v3.0 entfernt diesen Export vollständig.

Wenn du das veraltete image() aus astro:content verwendest, entferne es, da es nicht mehr existiert. Überprüfe Bilder stattdessen über den image-Helfer aus schema (EN):

src/content/config.ts
import { defineCollection, z, image } from "astro:content";
import { defineCollection, z } from "astro:content";
defineCollection({
schema: ({ image }) =>
z.object({
image: image(),
}),
});

Entfernt: Shiki-Theme-Namen vor Version 0.14

Abschnitt betitelt Entfernt: Shiki-Theme-Namen vor Version 0.14

In Astro v2.x wurden einige Shiki-Theme-Namen umbenannt, aber die ursprünglichen Namen wurden wegen der Abwärtskompatibilität beibehalten.

Astro v3.0 entfernt die ursprünglichen Namen zugunsten der umbenannten Theme-Namen.

Wenn dein Projekt eines der folgenden Themes verwendet, benenne es entsprechend seinem aktualisierten Namen um:

  • material-darker -> material-theme-darker
  • material-default -> material-theme
  • material-lighter -> material-theme-lighter
  • material-ocean -> material-theme-ocean
  • material-palenight -> material-theme-palenight

In Astro v2.x verwendete die class:list-Direktive (EN) eine benutzerdefinierte Implementierung, die von clsx inspiriert war und einige zusätzliche Features wie Deduplizierung und Unterstützung für Set enthielt.

Astro v3.0 verwendet clsx jetzt direkt für class:list, was keine Deduplizierung oder Unterstützung für Set-Werte bietet.

Ersetze alle Set-Elemente, die der class:list-Direktive übergeben werden, durch ein normales Array.

src/components/MyAstroComponent.astro
<Component class:list={[
'a',
'b',
new Set(['c', 'd'])
['c', 'd']
]} />

Entfernt: class:list als Prop übergeben

Abschnitt betitelt Entfernt: class:list als Prop übergeben

In Astro v2.x wurden class:list-Werte (EN) über Astro.props['class:list'] an Komponenten übermittelt.

Astro v3.0 normalisiert class:list-Werte zuerst zu einem String, bevor sie über Astro.props['class'] an Komponenten weitergegeben werden.

Entferne jeglichen Code, der den class:list-Prop erhält.

src/components/MyAstroComponent.astro
---
import { clsx } from 'clsx';
const { class: className, 'class:list': classList } = Astro.props;
const { class: className } = Astro.props;
---
<div
class:list={[className, classList]}
class:list={[className]}
/>

Entfernt: kebab-case Umwandlung für camelCase CSS-Variablen

Abschnitt betitelt Entfernt: kebab-case Umwandlung für camelCase CSS-Variablen

In Astro v2.x wurden camelCase CSS-Variablen, die dem style-Attribut übergeben wurden, sowohl in camelCase (wie geschrieben) als auch im kebab-case (für Abwärtskompatibilität beibehalten) gerendert.

Astro v3.0 entfernt die kebab-case Umwandlung für diese camelCase CSS-Variablennamen, und nur die ursprüngliche camelCase CSS-Variable wird gerendert.

src/components/MyAstroComponent.astro
---
const myValue = "red"
---
<!-- input -->
<div style={{ "--myValue": myValue }}></div>
<!-- output (Astro 2.x) -->
<div style="--my-value:var(--myValue);--myValue:red"></div>
<!-- output (Astro 3.0) -->
<div style="--myValue:red"></div>

Wenn du darauf vertraut hast, dass Astro kebab-case in deinen Styles umwandelt, aktualisiere deine bestehenden Styles zu camelCase, um fehlende Styles zu verhindern. Zum Beispiel:

src/components/MyAstroComponent.astro
<style>
div {
color: var(--my-value);
color: var(--myValue);
}
</style>

Entfernt: Automatisches Abflachen des Rückgabewerts von getStaticPaths()

Abschnitt betitelt Entfernt: Automatisches Abflachen des Rückgabewerts von getStaticPaths()

In Astro v2.x wurde der Rückgabewert von getStaticPaths() automatisch abgeflacht, um es dir zu ermöglichen, ein Array aus Arrays ohne Fehler zurückzugeben.

Astro v3.0 entfernt das automatische Abflachen des Rückgabewerts von getStaticPaths().

Wenn du ein Array von Arrays statt eines Arrays von Objekten zurückgibst (wie erwartet), sollten jetzt .flatMap und .flat verwendet werden, um sicherzustellen, dass du ein flaches Array zurückgibst.

Eine Fehlermeldung, die darauf hinweist, dass der Rückgabewert von getStaticPaths() ein Array aus Objekten sein muss (EN), wird bereitgestellt, wenn du deinen Code aktualisieren musst.

Verschoben: astro check erfordert jetzt ein externes Paket

Abschnitt betitelt Verschoben: astro check erfordert jetzt ein externes Paket

In Astro v2.x war astro check (EN) standardmäßig in Astro enthalten, und seine Abhängigkeiten waren in Astro gebündelt. Dies führte zu einem größeren Paket, unabhängig davon, ob du jemals astro check verwendet hast. Dies hat auch verhindert, dass du die Version von TypeScript und den Astro Language Server kontrollieren konntest.

Astro v3.0 verschiebt den Befehl astro check aus Astro und erfordert jetzt ein externes Paket @astrojs/check. Zusätzlich musst du typescript in deinem Projekt installieren, um den Befehl astro check zu verwenden.

Führe nach dem Upgrade auf Astro v3.0 den Befehl astro check aus und befolge die Anweisungen, um die erforderlichen Abhängigkeiten zu installieren. Alternativ kannst du @astrojs/check und typescript manuell in dein Projekt installieren.

Veraltet: build.excludeMiddleware und build.split

Abschnitt betitelt Veraltet: build.excludeMiddleware und build.split

In Astro v2.x wurden build.excludeMiddleware und build.split verwendet, um zu ändern, wie bestimmte Dateien beim Verwenden eines Adapters im SSR-Modus ausgegeben wurden.

Astro v3.0 ersetzt diese Erzeugungs-Konfigurationsoptionen durch neue SSR-Adapter-Konfigurationsoptionen, um die gleichen Aufgaben zu erledigen: edgeMiddleware und functionPerRoute.

Aktualisiere die Astro-Konfigurationsdatei, um die neuen Optionen nun direkt in der Adapter-Konfiguration zu verwenden.

astro.config.mjs
import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";
export default defineConfig({
build: {
excludeMiddleware: true
},
adapter: vercel({
edgeMiddleware: true
}),
});
astro.config.mjs
import { defineConfig } from "astro/config";
import netlify from "@astrojs/netlify/functions";
export default defineConfig({
build: {
split: true
},
adapter: netlify({
functionPerRoute: true
}),
});

In Astro v2.x ermöglichte die Konfiguration markdown.drafts das Vorhandensein von Entwürfen für Seiten, die im Dev-Server verfügbar waren, aber nicht für die Produktion erzeugt wurden.

Astro v3.0 deklariert dieses Feature als veraltet und bevorzugt die Verwendung von Inhalts-Sammlungen zum Umgang mit Entwurfsseiten durch manuelle Filterung, was mehr Kontrolle über das Feature ermöglicht.

Um weiterhin einige Seiten in deinem Projekt als Entwürfe zu kennzeichnen, verwende stattdessen Inhalts-Sammlungen (EN) und filtere Seiten manuell aus (EN), indem du die draft: true-Frontmatter-Eigenschaft verwendest.

Veraltet: Rückgabe eines einfachen Objekts an Endpunkten

Abschnitt betitelt Veraltet: Rückgabe eines einfachen Objekts an Endpunkten

In Astro v2.x konnten Endpunkte ein einfaches Objekt zurückgeben, das in eine JSON-Antwort umgewandelt wurde.

Astro v3.0 deklariert dieses Verhalten als veraltet und bevorzugt die direkte Rückgabe eines Response-Objekts.

Aktualisiere deine Endpunkte, um direkt ein Response-Objekt zurückzugeben.

endpoint.json.ts
export async function GET() {
return { body: { "title": "Bob's blog" }};
return new Response(JSON.stringify({ "title": "Bob's blog" }));
}

Wenn du wirklich das vorherige Format beibehalten musst, kannst du das ResponseWithEncoding-Objekt verwenden, aber beachte, dass es in Zukunft veraltet sein wird.

endpoint.json.ts
export async function GET() {
return { body: { "title": "Bob's blog" } };
return new ResponseWithEncoding({ body: { "title": "Bob's blog" }});
}

Standardwert geändert: verbatimModuleSyntax in tsconfig.json-Voreinstellungen

Abschnitt betitelt Standardwert geändert: verbatimModuleSyntax in tsconfig.json-Voreinstellungen

In Astro v2.x war die Einstellung verbatimModuleSyntax standardmäßig deaktiviert, wobei ihr TypeScript 4.x-Äquivalent importsNotUsedAsValues in der strict-Voreinstellung aktiviert war.

In Astro v3.0 ist verbatimModuleSyntax in jeder Voreinstellung aktiviert.

Diese Option erfordert, dass Typen mit der Syntax import type importiert werden.

src/components/MyAstroComponent.astro
---
import { type CollectionEntry, getEntry } from "astro:content";
---

Wir empfehlen, diese Option aktiviert zu lassen und deine Typen ordnungsgemäß mit type zu importieren (wie oben gezeigt). Sollte es zu Problemen kommen, kannst du die Option deaktivieren, indem du verbatimModuleSyntax: false in deiner tsconfig.json-Datei setzt.

tsconfig.json
{
"compilerOptions": {
"verbatimModuleSyntax": false
}
}

In Astro v2.x lief Astro standardmäßig auf Port 3000.

Astro v3.0 ändert den Standardport (EN) zu 4321. 🚀

Aktualisiere alle vorhandenen Verweise auf localhost:3000, zum Beispiel in Tests oder in deiner README, um den neuen Port localhost:4321 widerzuspiegeln.

Standardwert geändert: import.meta.env.BASE_URL trailingSlash

Abschnitt betitelt Standardwert geändert: import.meta.env.BASE_URL trailingSlash

In Astro v2.x hat import.meta.env.BASE_URL standardmäßig deine base (EN)-Einstellung in Kombination mit einem trailingSlash (EN) um ein Schrägstrichsuffix erweitert. trailingSlash: "ignore" hat ebenfalls ein Schrägstrichsuffix hinzugefügt.

Astro v3.0 fügt import.meta.env.BASE_URL standardmäßig nicht mehr mit einem Schrägstrichsuffix hinzu, auch nicht wenn trailingSlash: "ignore" festgelegt ist. (Das bestehende Verhalten von base in Kombination mit trailingSlash: "always" oder trailingSlash: "never" bleibt unverändert.)

Wenn deine base bereits ein Schrägstrichsuffix hat, ist keine Änderung erforderlich.

Wenn deine base kein Schrägstrichsuffix hat, füge einen hinzu, wenn du das vorherige Standardverhalten (oder trailingSlash: "ignore") beibehalten möchtest:

astro.config.mjs
import { defineConfig } from "astro/config";
export default defineConfig({
base: 'my-base',
base: 'my-base/',
});

In Astro v2.x hat Astro dein ausgegebenes HTML nur komprimiert, wenn compressHTML (EN) explizit auf true gesetzt war. Der Standardwert war false.

Astro v3.0 komprimiert jetzt standardmäßig das ausgegebene HTML.

Du kannst jetzt compressHTML: true aus deiner Konfiguration entfernen, da dies das neue Standardverhalten ist.

astro.config.mjs
import { defineConfig } from "astro/config";
export default defineConfig({
compressHTML: true
})

Du musst nun compressHTML: false setzen, um die HTML-Komprimierung nicht zu verwenden.

Standardwert geändert: scopedStyleStrategy

Abschnitt betitelt Standardwert geändert: scopedStyleStrategy

In Astro v2.x war der Standardwert von scopedStyleStrategy (EN) "where".

Astro v3.0 führt einen neuen Standardwert ein: "attribute". Standardmäßig werden Styles jetzt mit data-*-Attributen angewendet.

Um das aktuelle Style-Scoping deines Projekts beizubehalten, aktualisiere die Konfigurationsdatei auf den vorherigen Standardwert:

astro.config.mjs
import { defineConfig } from "astro/config";
export default defineConfig({
scopedStyleStrategy: "where"
})

Standardwert geändert: inlineStyleSheets

Abschnitt betitelt Standardwert geändert: inlineStyleSheets

In Astro v2.x wurden standardmäßig alle Projekt-Styles als Link-Tags gesendet. Du konntest die Option build.inlineStylesheets (EN) verwenden, um Styles stattdessen direkt in <style>-Tags einzubetten: Mit der Einstellung "always" wurden alle Styles eingebettet, und mit "auto" nur Styles unterhalb einer bestimmten Größe. Die Standardvoreinstellung war "never".

Astro v3.0 ändert den Standardwert von inlineStylesheets zu "auto". Stylesheets kleiner als ViteConfig.build.assetsInlineLimit (Standard: 4 KB) werden standardmäßig eingefügt. Andernfalls werden Projekt-Styles in externen Stylesheets gesendet.

Wenn du das aktuelle Verhalten deines Projekts beibehalten möchtest, setze build.inlineStylesheets auf den vorherigen Standardwert "never":

astro.config.mjs
import { defineConfig } from "astro/config";
export default defineConfig({
build: {
inlineStylesheets: "never"
}
})

In Astro v2.x war Squoosh der Standard-Bildverarbeitungsdienst (EN).

Astro v3.0 enthält jetzt standardmäßig Sharp als Bildverarbeitungsdienst und bietet stattdessen eine Konfigurationsoption, um Squoosh zu verwenden.

Wenn du Squoosh weiterhin für die Verarbeitung deiner Bilder verwenden möchtest, aktualisiere deine Konfiguration wie folgt:

astro.config.mjs
import { defineConfig, squooshImageService } from "astro/config";
export default defineConfig({
image: {
service: squooshImageService(),
}
})

Geändert: Groß- und Kleinschreibung der HTTP-Anforderungsmethoden

Abschnitt betitelt Geändert: Groß- und Kleinschreibung der HTTP-Anforderungsmethoden

In Astro v2.x wurden HTTP-Anforderungsmethoden mit Kleinbuchstaben verwendet: get, post, put, all und del.

Astro v3.0 verwendet Großbuchstaben, einschließlich DELETE anstelle von del.

Benenne alle Funktionen in ihre Großbuchstaben-Äquivalente um:

  • get to GET
  • post to POST
  • put to PUT
  • all to ALL
  • del to DELETE
endpoint.ts
export function get() {
export function GET() {
return new Response(JSON.stringify({ "title": "Bob's blog" }));
}

Geändert: Konfiguration für mehrere JSX-Frameworks

Abschnitt betitelt Geändert: Konfiguration für mehrere JSX-Frameworks

In Astro v2.x konntest du mehrere JSX-Framework-Integrationen (React, Solid, Preact) im selben Projekt verwenden, ohne angeben zu müssen, welche Dateien zu welchem Framework gehören.

Astro v3.0 erfordert nun, dass du angibst, welches Framework für deine Dateien verwendet werden soll, indem du neue include- und exclude-Integrationskonfigurationsoptionen verwendest, wenn du mehrere JSX-Framework-Integrationen installiert hast. Dies ermöglicht es Astro, die Verwendung eines einzigen Frameworks besser zu unterstützen, sowie fortgeschrittene Funktionen wie React Fast Refresh.

Wenn du mehrere JSX-Frameworks im selben Projekt verwendest, setze include (und optional exclude) auf ein Array von Dateien und/oder Ordnern. Wildcards können verwendet werden, um mehrere Dateipfade einzuschließen.

Wir empfehlen, gemeinsame Framework-Komponenten im selben Ordner zu speichern (z.B. /components/react/ und /components/solid/), um die Angabe deiner Includes zu erleichtern, aber dies ist nicht erforderlich:

import { defineConfig } from 'astro/config';
import preact from '@astrojs/preact';
import react from '@astrojs/react';
import svelte from '@astrojs/svelte';
import vue from '@astrojs/vue';
import solid from '@astrojs/solid-js';
export default defineConfig({
// Aktiviere viele Frameworks, um verschiedene Arten von Komponenten zu unterstützen.
// `include` ist nicht erforderlich, wenn du nur ein Framework verwendest!
integrations: [
preact({
include: ['**/preact/*']
}),
react({
include: ['**/react/*']
}),
solid({
include: ['**/solid/*'],
}),
]
});

Geändert: Astro.cookies.get(key) kann undefined zurückgeben

Abschnitt betitelt Geändert: Astro.cookies.get(key) kann undefined zurückgeben

In Astro v2.x hat Astro.cookies.get(key) immer ein AstroCookie-Objekt zurückgegeben, auch wenn kein Cookie existierte. Um auf dessen Existenz zu prüfen, musstest du Astro.cookies.has(key) verwenden.

Astro v3.0 gibt für Astro.cookies.get(key) nun undefined zurück, wenn kein Cookie existiert.

Diese Änderung wird keinen Code unbrauchbar machen, der auf die Existenz des Astro.cookie-Objekts überprüft, bevor Astro.cookies.get(key) verwendet wird, ist jedoch jetzt nicht mehr erforderlich.

Du kannst ohne Probleme jeglichen Code entfernen, der has() verwendet, um zu überprüfen, ob der Wert von Astro.cookies undefined ist:

if (Astro.cookies.has(id)) {
const id = Astro.cookies.get(id)!;
}
const id = Astro.cookies.get(id);
if (id) {
}

Geändert: Programmatisches Ausführen der Astro Kommandozeilen­schnittstelle (CLI)

Abschnitt betitelt Geändert: Programmatisches Ausführen der Astro Kommandozeilen­schnittstelle (CLI)

In Astro v2.x exportierte und startete der Eintrittspunkt des Pakets "astro" die Astro CLI direkt. Es wird nicht empfohlen, Astro auf diese Weise in der Praxis auszuführen.

Astro v3.0 entfernt die CLI aus dem Eintrittspunkt und exportiert einen neuen Satz experimenteller JavaScript-APIs, einschließlich dev(), build(), preview() und sync().

Um die Astro Kommandozeilenschnittstelle programmatisch auszuführen (EN), verwende die neuen experimentellen JavaScript-APIs:

import { dev, build } from "astro";
// Starte den Astro-Entwicklungsserver
const devServer = await dev();
await devServer.stop();
// Erzeuge dein Astro-Projekt
await build();

Geändert: Pfade für den Export von internen Astro-API-Einstiegspunkten

Abschnitt betitelt Geändert: Pfade für den Export von internen Astro-API-Einstiegspunkten

In Astro v2.x konntest du interne Astro-APIs aus astro/internal/* und astro/runtime/server/* importieren.

Astro v3.0 entfernt die beiden Einstiegspunkte zugunsten des vorhandenen Einstiegspunkts astro/runtime/*. Zusätzlich wurde ein neuer Export astro/compiler-runtime für compiler-spezifischen Laufzeitcode hinzugefügt.

Diese sind Einstiegspunkte für Astros interne API und sollten sich nicht auf dein Projekt auswirken. Aber wenn du diese Einstiegspunkte verwendest, aktualisiere sie wie unten gezeigt:

import 'astro/internal/index.js';
import 'astro/runtime/server/index.js';
import 'astro/server/index.js';
import 'astro/runtime/server/index.js';
import { transform } from '@astrojs/compiler';
const result = await transform(source, {
internalURL: 'astro/runtime/server/index.js',
internalURL: 'astro/compiler-runtime',
// ...
});

Du kennst eine gute Ressource für Astro v3.0? Bearbeite diese Seite und füge unten einen Link hinzu!

Es gibt derzeit keine bekannten Probleme.