astro-components v3.0 — Astro 6, Tailwind 4, neue Lizenz

Heute habe ich @wendermedia/astro-components v3.0.0 auf npm veröffentlicht. Das ist kein Patch und kein Minor-Release — es ist ein Major-Bump mit drei zusammenhängenden Migrationen: Astro 5 → 6, Tailwind 3 → 4 in den Templates, und Lizenzwechsel von MIT zur Wender Media Source License v1.0.

Warum drei Migrationen in einem Release

Drei Breaking Changes in einem einzigen Major-Bump sehen wie schlechtes Engineering aus — aber die Alternative wäre schlimmer. Drei separate Major-Releases (3.0 für Astro 6, 4.0 für Tailwind 4 in Templates, 5.0 für die Lizenz) hätten Konsumenten gezwungen, drei Migrationen hintereinander durchzuführen. Das ist Reibung ohne Mehrwert.

Stattdessen: eine Migration, eine Migration-Anleitung, ein einziger CHANGELOG-Eintrag. Wer auf v2.x bleiben will (weil die Codebasis noch auf Astro 5 läuft), pinnt einfach @wendermedia/astro-components@2.1.0 und bekommt weiterhin MIT-lizenzierten Code.

Astro 5 → 6: was sich ändert

Astro 6 ist nicht nur ein Dependency-Bump. Es entfernt mehrere APIs vollständig und ändert die Standardwerte einiger anderer:

Die Library selbst (src/, integrations/) ist erstaunlich unbeeinflusst von diesen Änderungen — null Astro.glob-Aufrufe, null <ViewTransitions />, null Content Collections im Source. Die ganze Migrationsarbeit liegt in den Templates und Bundles, also den Scaffolds, die Konsumenten in ihre eigenen Projekte kopieren.

Tailwind 4 in Templates: aus Integration wird Vite-Plugin

In v2.x nutzten alle Templates @astrojs/tailwind (die offizielle Astro-Integration). Diese Integration ist seit Tailwind 4 deprecated und unterstützt Astro 6 nicht. Der Wechsel:

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

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

import { defineConfig } from 'astro/config';
import tailwindcss from '@tailwindcss/vite';

export default defineConfig({
  integrations: [],
  vite: {
    plugins: [tailwindcss()],
  },
});

Plus: tailwind.config.js ist tot. Tailwind 4 liest die JS-Config nicht mehr — alle Tokens leben jetzt als CSS Custom Properties in @theme-Blöcken in der global.css. Das ist ein eigenes Migrations-Thema, aber für Library-Konsumenten relevant: wer ein Template kopiert, muss auch sein eigenes Theme-System auf @theme umstellen.

Storybook 8 → 10: Addons absorbiert

Storybook 9 hat die meisten Essential-Addons in den Core absorbiert. Storybook 10 hat die leeren Stub-Pakete entfernt. Was vorher als separate Packages installiert wurde, lebt jetzt als Subpath-Export im storybook-Hauptpaket:

Praktisch hieß das: vier Pakete aus den devDependencies entfernen, ein neues hinzufügen (@storybook/addon-docs für MDX/Meta-Parsing in Welcome-Stories), drei Subpath-Imports in .storybook/manager.ts umschreiben. Die 158 Story-Dateien selbst blieben unverändert — der kanonische Meta/StoryObj-Import aus @storybook/web-components ist auch in v10 noch gültig.

Lizenzwechsel: MIT → Wender Media Source License v1.0

Die spannendste Änderung. v2.x lief unter MIT-Lizenz. v3.0 läuft unter einer neuen, selbstgeschriebenen Lizenz: der Wender Media Source License v1.0 (WMSL v1.0). SPDX-Identifier: LicenseRef-Wender-Media-Source-1.0.

Das ist kein OSI-genehmigter Open-Source-Lizenztext. Es ist eine Source-Available-Lizenz mit Copyleft-Anteilen, inspiriert von der Struktur der Mozilla Public License 2.0:

Wer MIT-Code braucht, nutzt v2.1.0. Wer auf Astro 6 ist und mit der WMSL leben kann, bekommt v3.0 mit allen neuen Patterns.

Die Asymmetrie zwischen Library- und Site-Migration

Eine Library zu migrieren, die in einer Library-Repo lebt (ein npm-Paket, kein Site-Build), hat eine Eigenheit: das Source-Code-Verzeichnis (src/) ist erstaunlich neutral gegenüber Astro-Major-Bumps. Die ganze Arbeit konzentriert sich in vier disjunkten Bereichen:

Die vier Bereiche überlappen sich nicht — LICENSE/package.json/README im Root, templates/, bundles/ und .storybook/ sind dateiscope-disjunkt. Sobald man diese Asymmetrie sieht, schreibt sich die Migrationsstrategie von selbst: jeder Layer kann unabhängig bearbeitet werden, kein Git-Worktree-Tanz nötig, weil nichts kollidiert. Die Barrel-Datei index.ts der Library ist im Grunde neutral — nur der Copyright-Header und der Versionsstring ändern sich.

Konsumenten-Migration: was du tun musst

Wenn du @wendermedia/astro-components in deinem Projekt nutzt und auf v3.0 upgraden willst, gibt es eine vollständige Migrationsanleitung im Repo. Die Kurzfassung:

Was als Nächstes kommt

v3.0 ist der Beginn einer neuen Linie. v3.x wird Astro 6 als Plattform behalten, aber die 158 Komponenten weiter ausbauen. Zwei Dinge sind in der Pipeline:

1. React/Vue/Svelte/Solid-Komponenten — die framework-agnostischen Versionen unter integrations/react/, integrations/vue/ etc. werden um etwa 30 Komponenten erweitert.
2. Experimentelle Komponenten-Generierungs-CLI — wm-components new <Beschreibung> scaffoldet neue Komponenten aus einer kurzen Beschreibung, passend zum Design-System. Experimentell, kommt mit v3.2.

Das v2.1.0-Pin bleibt als langfristige LTS-Option für Astro 5-Projekte verfügbar — keine Updates, aber auch keine Downloads-Penalty.

Links:

• npm-Paket
• GitHub-Repository
• Migrations-Anleitung v2 → v3
• Vorheriger Artikel: v2.0-Launch