astro-components v3.0 — Astro 6, Tailwind 4, nueva licencia

Hoy publiqué @wendermedia/astro-components v3.0.0 en npm. No es un parche ni un release menor — es un major bump que combina tres migraciones conectadas: Astro 5 → 6, Tailwind 3 → 4 en los templates, y cambio de licencia de MIT a la Wender Media Source License v1.0.

Por qué tres migraciones en un solo release

Tres breaking changes en un solo major bump parecen mala ingeniería — pero la alternativa sería peor. Tres releases mayores separados (3.0 para Astro 6, 4.0 para Tailwind 4 en templates, 5.0 para la licencia) habrían forzado a los consumidores a pasar por tres migraciones consecutivas. Eso es fricción sin valor.

En su lugar: una migración, una guía de migración, una entrada en CHANGELOG. Quien quiera quedarse en v2.x (porque su código todavía está en Astro 5) simplemente fija @wendermedia/astro-components@2.1.0 y sigue recibiendo código bajo licencia MIT.

Astro 5 → 6: qué cambia

Astro 6 no es solo un bump de dependencias. Elimina varias APIs por completo y cambia los valores predeterminados de otras:

La librería en sí (src/, integrations/) está sorprendentemente intacta frente a estos cambios — cero llamadas a Astro.glob, cero <ViewTransitions />, cero content collections en el source. Todo el trabajo de migración vive en los templates y bundles, los scaffolds que los consumidores copian a sus propios proyectos.

Tailwind 4 en templates: de integración a plugin de Vite

En v2.x todos los templates usaban @astrojs/tailwind (la integración oficial de Astro). Esa integración está deprecated desde Tailwind 4 y no soporta Astro 6. El cambio:

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()],
  },
});

Además: tailwind.config.js está muerto. Tailwind 4 ya no lee el config JS — todos los tokens viven como CSS custom properties en bloques @theme dentro de global.css. Es un tema de migración propio, pero relevante para los consumidores de la librería: quien copia un template también debe migrar su sistema de temas a @theme.

Storybook 8 → 10: addons absorbidos

Storybook 9 absorbió la mayoría de los essential addons en el core. Storybook 10 eliminó los paquetes stub vacíos. Lo que antes eran paquetes separados ahora vive como subpath exports dentro del paquete principal storybook:

En la práctica: quitar cuatro paquetes de devDependencies, agregar uno nuevo (@storybook/addon-docs para parsing de MDX/Meta en historias Welcome), reescribir tres subpath imports en .storybook/manager.ts. Los 158 archivos de stories quedaron sin tocar — el import canónico de Meta/StoryObj desde @storybook/web-components sigue siendo válido en v10.

Cambio de licencia: MIT → Wender Media Source License v1.0

El cambio más interesante. v2.x corría bajo licencia MIT. v3.0 corre bajo una licencia nueva y propia: la Wender Media Source License v1.0 (WMSL v1.0). Identificador SPDX: LicenseRef-Wender-Media-Source-1.0.

No es una licencia OSI-approved open source. Es una licencia source-available con elementos de copyleft, inspirada en la estructura de la Mozilla Public License 2.0:

Si necesitas código MIT, usa v2.1.0. Si estás en Astro 6 y puedes vivir con WMSL, obtienes v3.0 con todos los nuevos patterns.

La asimetría entre migración de librería y sitio

Migrar una librería que vive en un repo de librería (un paquete npm, no un site build) tiene una particularidad: el directorio de código fuente (src/) está sorprendentemente neutral frente a major bumps de Astro. Todo el trabajo se concentra en cuatro áreas disjuntas:

Las cuatro áreas no se solapan — LICENSE/package.json/README en la raíz, templates/, bundles/, y .storybook/ tienen scope de archivos disjunto. Una vez que ves esta asimetría, la estrategia de migración se escribe sola: cada capa puede tratarse independientemente, sin necesidad de hacer dance con git worktrees porque nada colisiona. El archivo barrel index.ts de la librería es prácticamente neutral — solo se actualiza el header de copyright y el string de versión.

Migración de consumidores: qué tienes que hacer

Si usas @wendermedia/astro-components en tu proyecto y quieres actualizar a v3.0, hay una guía de migración completa en el repo. La versión corta:

Qué viene después

v3.0 es el inicio de una nueva línea. v3.x mantendrá Astro 6 como plataforma, pero los 158 componentes seguirán creciendo. Dos cosas están en el pipeline:

1. Componentes React/Vue/Svelte/Solid — las versiones agnósticas de framework bajo integrations/react/, integrations/vue/ etc. ganarán unos 30 componentes más.
2. CLI experimental de generación de componentes — wm-components new <descripción> scaffoldea componentes nuevos a partir de una descripción corta, alineados con el sistema de diseño. Experimental, llega con v3.2.

El pin de v2.1.0 sigue como opción LTS de largo plazo para proyectos en Astro 5 — sin actualizaciones, pero sin penalty de descargas tampoco.

Enlaces:

• Paquete en npm
• Repositorio en GitHub
• Guía de migración v2 → v3
• Artículo anterior: lanzamiento de v2.0