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.

Astro-Aktualisierung

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.

# Upgrade auf Astro v3.x
npm install astro@latest

# Beispiel: React- und Tailwind-Integrationen aktualisieren
npm install @astrojs/react@latest @astrojs/tailwind@latest

# Upgrade auf Astro v3.x
pnpm install astro@latest

# Beispiel: React- und Tailwind-Integrationen aktualisieren
pnpm install @astrojs/react@latest @astrojs/tailwind@latest

# Upgrade auf Astro v3.x
yarn add astro@latest

# Beispiel: React- und Tailwind-Integrationen aktualisieren
yarn add @astrojs/react@latest @astrojs/tailwind@latest

Experimentelle Optionen von Astro v3.0 wurden entfernt

Entferne die folgenden experimentellen Optionen aus 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 Breaking Changes

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.

Entfernt: Unterstützung für Node 16

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.

Was soll ich tun?

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

Überprüfe deine lokale Version von Node mit:
Terminal-Fenster
```
node -v
```
Ü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.

18.14.1

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).

Was soll ich tun?

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

npm install typescript@latest --save-dev

Entfernt: `@astrojs/image`

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.

Was soll ich tun?

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!

import { defineConfig } from 'astro/config';
import image from '@astrojs/image';

export default defineConfig({
  integrations: [
    image(),
  ]
})

Entfernt: `<Markdown />`-Komponente

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.

Was soll ich tun?

Entferne alle Verwendungen von @astrojs/markdown-component.

---
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.

Entfernt: Veraltete 1.x APIs

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.

Was soll ich tun?

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

Veraltete Konfigurationsoptionen: Siehe die 0.26 Migrations-Anleitung (EN)
Veraltete Skript-/Style-Attributtypen: Siehe die 0.26 Migrations-Anleitung (EN)

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.

Was soll ich tun?

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

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.

Was soll ich tun?

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):

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

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.

Was soll ich tun?

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

Entfernt: `class:list`-Features

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.

Was soll ich tun?

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

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

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.

Was soll ich tun?

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

---
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

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.

---
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>

Was soll ich tun?

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:

<style>
  div {
   color: var(--my-value);
   color: var(--myValue);
  }
</style>

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().

Was soll ich tun?

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

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.

Was soll ich tun?

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`

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.

Was soll ich tun?

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

import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";

export default defineConfig({
    build: {
      excludeMiddleware: true
    },
    adapter: vercel({
      edgeMiddleware: true
    }),
});

import { defineConfig } from "astro/config";
import netlify from "@astrojs/netlify/functions";

export default defineConfig({
     build: {
        split: true
     },
     adapter: netlify({
        functionPerRoute: true
     }),
});

Veraltet: `markdown.drafts`

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.

Was soll ich tun?

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

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.

Was soll ich tun?

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

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.

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

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.

Was soll ich tun?

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

---
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.

{
  "compilerOptions": {
    "verbatimModuleSyntax": false
  }
}

Standardwert geändert: Port `3000`

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

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

Was soll ich tun?

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`

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.)

Was soll ich tun?

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:

import { defineConfig } from "astro/config";

export default defineConfig({
  base: 'my-base',
  base: 'my-base/',
});

Standardwert geändert: `compressHTML`

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.

Was soll ich tun?

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

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`

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.

Was soll ich tun?

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

import { defineConfig } from "astro/config";

export default defineConfig({
  scopedStyleStrategy: "where"
})

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.

Was soll ich tun?

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

import { defineConfig } from "astro/config";

export default defineConfig({
   build: {
    inlineStylesheets: "never"
  }
})

Standardwert geändert: Bilderdienst

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.

Was soll ich tun?

Bei Verwendung eines strikten Paketmanagers wie pnpm musst du möglicherweise Sharp manuell in dein Projekt installieren, obwohl es eine Abhängigkeit von Astro ist:

pnpm install sharp

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

import { defineConfig, squooshImageService } from "astro/config";

export default defineConfig({
  image: {
    service: squooshImageService(),
  }
})

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.

Was soll ich tun?

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

get to GET
post to POST
put to PUT
all to ALL
del to DELETE

export function get() {
export function GET() {
    return new Response(JSON.stringify({ "title": "Bob's blog" }));
}

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.

Was soll ich tun?

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

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.

Was soll ich tun?

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 Kommandozeilenschnittstelle (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().

Was soll ich tun?

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

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.

Was soll ich tun?

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',
  // ...
});

Community-Ressourcen

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

Bekannte Probleme

Es gibt derzeit keine bekannten Probleme.

Auf Astro v3 aktualisieren

Astro-Aktualisierung

Experimentelle Optionen von Astro v3.0 wurden entfernt

Astro v3.0 Breaking Changes

Entfernt: Unterstützung für Node 16

Was soll ich tun?

Entfernt: Unterstützung für TypeScript 4

Was soll ich tun?

Entfernt: @astrojs/image

Was soll ich tun?

Entfernt: <Markdown />-Komponente

Was soll ich tun?

Entfernt: Veraltete 1.x APIs

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

Entfernt: Shiki-Theme-Namen vor Version 0.14

Was soll ich tun?

Entfernt: class:list-Features

Was soll ich tun?

Entfernt: class:list als Prop übergeben

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

Verschoben: astro check erfordert jetzt ein externes Paket

Was soll ich tun?

Veraltet: build.excludeMiddleware und build.split

Was soll ich tun?

Veraltet: markdown.drafts

Was soll ich tun?

Veraltet: Rückgabe eines einfachen Objekts an Endpunkten

Was soll ich tun?

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

Was soll ich tun?

Standardwert geändert: Port 3000

Was soll ich tun?

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

Was soll ich tun?

Standardwert geändert: compressHTML

Was soll ich tun?

Standardwert geändert: scopedStyleStrategy

Was soll ich tun?

Standardwert geändert: inlineStyleSheets

Was soll ich tun?

Standardwert geändert: Bilderdienst

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

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

Was soll ich tun?

Community-Ressourcen

Bekannte Probleme

Entfernt: `@astrojs/image`

Entfernt: `<Markdown />`-Komponente

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

Entfernt: `class:list`-Features

Entfernt: `class:list` als Prop übergeben

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

Verschoben: `astro check` erfordert jetzt ein externes Paket

Veraltet: `build.excludeMiddleware` und `build.split`

Veraltet: `markdown.drafts`

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

Standardwert geändert: Port `3000`

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

Standardwert geändert: `compressHTML`

Standardwert geändert: `scopedStyleStrategy`

Standardwert geändert: `inlineStyleSheets`

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

Geändert: Programmatisches Ausführen der Astro Kommandozeilenschnittstelle (CLI)