astro-components v3.0 — Astro 6, Tailwind 4, new license

Today I published @wendermedia/astro-components v3.0.0 to npm. This isn’t a patch or a minor — it’s a major bump bundling three connected migrations: Astro 5 → 6, Tailwind 3 → 4 in the templates, and a license change from MIT to the Wender Media Source License v1.0.

Why three migrations in one release

Three breaking changes in a single major bump look like bad engineering — but the alternative would be worse. Three separate major releases (3.0 for Astro 6, 4.0 for Tailwind 4 in templates, 5.0 for the license) would have forced consumers through three back-to-back migrations. That’s friction without value.

Instead: one migration, one migration guide, one CHANGELOG entry. Anyone who wants to stay on v2.x (because their codebase is still on Astro 5) just pins @wendermedia/astro-components@2.1.0 and continues to get MIT-licensed code.

Astro 5 → 6: what changes

Astro 6 isn’t just a dependency bump. It removes several APIs entirely and changes defaults for others:

The library itself (src/, integrations/) is surprisingly unaffected by these changes — zero Astro.glob calls, zero <ViewTransitions />, zero content collections in source. All the migration work lives in the templates and bundles — the scaffolds consumers copy into their own projects.

Tailwind 4 in templates: integration becomes Vite plugin

In v2.x all templates used @astrojs/tailwind (the official Astro integration). That integration has been deprecated since Tailwind 4 and does not support Astro 6. The swap:

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 is dead. Tailwind 4 doesn’t read the JS config anymore — all tokens live as CSS custom properties in @theme blocks in global.css. That’s its own migration topic, but relevant for library consumers: anyone copying a template also has to migrate their own theme system to @theme.

Storybook 8 → 10: addons absorbed

Storybook 9 absorbed most essential addons into core. Storybook 10 removed the empty stub packages entirely. What used to be separate packages now lives as subpath exports in the main storybook package:

In practice: remove four packages from devDependencies, add one new (@storybook/addon-docs for MDX/Meta parsing in Welcome stories), rewrite three subpath imports in .storybook/manager.ts. The 158 story files themselves were untouched — the canonical Meta/StoryObj import from @storybook/web-components is still valid in v10.

License change: MIT → Wender Media Source License v1.0

The most interesting change. v2.x ran under the MIT license. v3.0 runs under a new, custom-written license: the Wender Media Source License v1.0 (WMSL v1.0). SPDX identifier: LicenseRef-Wender-Media-Source-1.0.

This is not an OSI-approved open-source license. It is a source-available license with copyleft elements, inspired by the structure of the Mozilla Public License 2.0:

If you need MIT code, use v2.1.0. If you’re on Astro 6 and can live with WMSL, you get v3.0 with all the new patterns.

The library vs site migration asymmetry

Migrating a library that lives in a library repo (an npm package, not a site build) has a quirk: the source code directory (src/) is surprisingly neutral to Astro major bumps. All the work concentrates in four disjoint areas:

The four areas don’t overlap — LICENSE/package.json/README at the root, templates/, bundles/, and .storybook/ are file-scope-disjoint. Once you see this asymmetry, the migration strategy writes itself: each layer can be tackled independently, no git worktree dance needed because nothing collides. The library’s barrel index.ts is essentially neutral — only the copyright header and version string change.

Consumer migration: what you have to do

If you use @wendermedia/astro-components in your project and want to upgrade to v3.0, there’s a complete migration guide in the repo. The short version:

What’s next

v3.0 is the start of a new line. v3.x will keep Astro 6 as the platform, but the 158 components will keep growing. Two things are in the pipeline:

1. React/Vue/Svelte/Solid components — the framework-agnostic versions under integrations/react/, integrations/vue/ etc. will gain about 30 more components.
2. Experimental component generation CLI — wm-components new <description> scaffolds new components from a brief description, matching the design system. Experimental, ships with v3.2.

The v2.1.0 pin remains as a long-term LTS option for Astro 5 projects — no updates, but no download penalty either.

Links:

• npm package
• GitHub repository
• Migration guide v2 → v3
• Previous article: v2.0 launch