Saltar al contenido

Guía de Actualización Legacy v0.x

Esta guía te ayudará a actualizar a través de cambios importantes en versiones pre-v1 de Astro.

Puedes actualizar la versión de Astro en tu proyecto a la última versión usando tu gestor de paquetes. Si estás usando integraciones de Astro, también querrás actualizarlas a la última versión.

Ventana de la terminal
# updates the astro dependency:
npm upgrade astro
# or, to update all dependencies:
npm upgrade

Lee la guía a continuación para los aspectos más destacados e instrucciones sobre cómo manejar los cambios importantes.

Astro v1.0 introduce algunos cambios que debes conocer al migrar desde versiones v0.x y v1.0-beta. Consulta a continuación para más detalles.

Astro v1.0 ha actualizado de Vite 2 a Vite 3. Hemos manejado la mayor parte de la actualización por ti dentro de Astro; sin embargo, algunos comportamientos sutiles de Vite pueden cambiar entre versiones. Consulta la Guía de Migración de Vite oficial si tienes problemas.

Ahora puedes usar el nuevo helper Astro.url para construir tu propia URL canónica desde la URL de la página/solicitud actual.

// Before:
const canonicalURL = Astro.canonicalURL;
// After:
const canonicalURL = new URL(Astro.url.pathname, Astro.site);

La especificidad ahora se preservará en los estilos CSS scoped. Este cambio hará que la mayoría de los estilos scoped tengan precedencia sobre los estilos globales. Pero este comportamiento ya no está garantizado explícitamente.

Técnicamente, esto se logra usando la pseudo-clase :where() en lugar de usar clases directamente en la salida CSS de Astro.

Usamos el siguiente bloque de estilo en un componente de Astro como ejemplo:

<style>
div { color: red; } /* 0-0-1 specificity */
</style>

Anteriormente, Astro transformaba esto en el siguiente CSS, que tiene una especificidad de 0-1-1 — una especificidad mayor que el CSS original:

div.astro-XXXXXX { color: red; } /* 0-1-1 specificity */

Ahora, Astro envuelve el selector de clase con :where(), manteniendo la especificidad original:

div:where(.astro-XXXXXX) { color: red; } /* 0-0-1 specificity */

El aumento de especificidad anterior hacía difícil combinar estilos scoped en Astro con otros archivos CSS o librerías de estilos (p. ej. Tailwind, CSS Modules, Styled Components, Stitches). Este cambio permitirá que los estilos scoped de Astro funcionen consistentemente junto a ellos mientras se preservan los límites exclusivos que evitan que los estilos se apliquen fuera del componente.

Astro ya no soporta componentes ni expresiones JSX en páginas Markdown por defecto. Para soporte a largo plazo deberías migrar a la integración @astrojs/mdx.

Para facilitar la migración, un nuevo flag legacy.astroFlavoredMarkdown (removido en v2.0) puede usarse para re-habilitar las funcionalidades anteriores de Markdown.

Si no estás familiarizado con MDX, aquí hay algunos pasos que puedes seguir para convertir rápidamente un archivo existente de “Astro Flavored Markdown” a MDX. A medida que aprendas más sobre MDX, ¡siéntete libre de explorar otras formas de escribir tus páginas!

  1. Instala la integración @astrojs/mdx.

  2. Cambia las extensiones de tus archivos .md existentes a .mdx

  3. Elimina cualquier propiedad setup: de tu frontmatter, y escribe cualquier import statement debajo del frontmatter en su lugar.

    src/pages/posts/my-post.mdx
    ---
    layout: '../../layouts/BaseLayout.astro'
    setup: |
    import ReactCounter from '../../components/ReactCounter.jsx'
    title: 'Migrating to MDX'
    date: 2022-07-26
    tags: ["markdown", "mdx", "astro"]
    ---
    import ReactCounter from '../../components/ReactCounter.jsx'
    # {frontmatter.title}
    Here is my counter component, working in MDX:
    <ReactCounter client:load />
  4. Actualiza cualquier statement Astro.glob() que actualmente devuelva archivos .md para que ahora devuelvan tus archivos .mdx.

  5. Actualiza cualquier uso del componente <Content /> para usar el default export al importar MDX:

    src/pages/index.astro
    ---
    // Multiple imports with Astro.glob
    const mdxPosts = await Astro.glob('./posts/*.mdx');
    ---
    {mdxPosts.map(Post => <Post.default />)}
    src/pages/index.astro
    ---
    // Import a single page
    import { default as About } from './about.mdx';
    ---
    <About />

El componente integrado <Markdown /> de Astro se ha movido a un paquete separado. Para continuar usando este componente, ahora necesitarás instalar @astrojs/markdown-component y actualizar tus importaciones en consecuencia. Para más detalles, consulta el README de @astrojs/markdown.

El 4 de abril de 2022 lanzamos el Astro 1.0 Beta! 🎉

Si vienes de v0.25 o anterior, asegúrate de haber leído y seguido la Guía de Migración de v0.26 a continuación, que contenía varios cambios importantes.

El release v1.0.0-beta.0 de Astro no contenía cambios importantes. A continuación hay pequeños cambios que se introdujeron durante el periodo beta.

Los feeds RSS ahora deberían generarse usando el paquete @astrojs/rss, como se describe en nuestra guía de RSS.

Nuestra API de Configuración ha sido rediseñada para resolver algunos puntos evidentes de confusión que se habían acumulado durante el último año. La mayoría de las opciones de configuración simplemente se han movido o renombrado, lo que debería ser una actualización rápida para la mayoría de usuarios. Algunas opciones han sido refactorizadas más profundamente, y pueden requerir algunos cambios adicionales:

  • .buildOptions.site ha sido reemplazado por .site (tu dominio desplegado) y una nueva opción .base (tu subpath desplegado).
  • .markdownOptions ha sido reemplazado por .markdown, un objeto de configuración muy similar con algunos pequeños cambios para simplificar la configuración de Markdown.
  • .sitemap se ha movido a la integración @astrojs/sitemap.

Si ejecutas Astro con configuración legacy, verás una advertencia con instrucciones sobre cómo actualizar. Consulta nuestra Referencia de Configuración actualizada para más información sobre la actualización.

Lee RFC0019 para más contexto sobre estos cambios.

Astro v0.26 lanza una nueva API de Markdown para tu contenido. Esto incluyó tres cambios importantes para el usuario:

  • Ahora puedes importar/import() contenido markdown directamente usando una importación ESM.
  • Una nueva API Astro.glob(), para importaciones glob más fáciles (especialmente para Markdown).
  • CAMBIO IMPORTANTE: Astro.fetchContent() ha sido removido y reemplazado por Astro.glob()
  • CAMBIO IMPORTANTE: Los objetos Markdown tienen una interfaz actualizada.
// v0.25
let allPosts = Astro.fetchContent('./posts/*.md');
// v0.26+
let allPosts = await Astro.glob('./posts/*.md');

Al migrar, ten cuidado con la nueva interfaz del objeto Markdown. Frontmatter, por ejemplo, se ha movido a la propiedad .frontmatter, así que referencias como post.title deberían cambiar a post.frontmatter.title.

Esto debería resolver muchos problemas para usuarios de Markdown, incluyendo algunas mejoras de rendimiento para sitios más grandes.

Lee RFC0017 para más contexto sobre estos cambios.

Las etiquetas <script> en componentes de Astro ahora se construyen, empaquetan y optimizan por defecto. Esto completa un movimiento a largo plazo para hacer la sintaxis de componentes de Astro más consistente, coincidiendo con el comportamiento de optimización por defecto que tienen nuestras etiquetas <style> hoy.

Esto incluye algunos cambios a tener en cuenta:

  • IMPORTANTE: <script hoist> es el nuevo comportamiento por defecto de <script>. El atributo hoist ha sido removido. Para usar el nuevo comportamiento por defecto, asegúrate de que no haya otros atributos en la etiqueta <script>. Por ejemplo, remueve type="module" si lo estabas usando antes.
  • Nueva directiva <script is:inline>, para revertir una etiqueta <script> al comportamiento por defecto anterior (sin construir, sin empaquetar, sin modificar por Astro).
  • Nueva directiva <style is:inline>, para dejar una etiqueta de estilo inline en la plantilla de página (similar al comportamiento anterior de <script>).
  • Nueva directiva <style is:global> para reemplazar <style global> en un futuro release.
// v0.25
<script hoist type="module">
// v0.26+
<script>

Consulta cómo usar scripts del lado del cliente en Astro para todos los detalles.

Lee RFC0016 para más contexto sobre estos cambios.

Astro.request ha cambiado de nuestro objeto personalizado a un objeto Request estándar. Esto es parte de un proyecto para usar más APIs estándar web, especialmente donde SSR está involucrado.

Esto incluye algunos cambios a tener en cuenta:

  • Cambia Astro.request para convertirse en un objeto Request.
  • Mueve Astro.request.params a Astro.params.
  • Mueve Astro.request.canonicalURL a Astro.canonicalURL.

Lee RFC0018 para más contexto sobre estos cambios.

  • Mejora la API Astro.slots para soportar pasar argumentos a slots basados en funciones. Esto permite componentes utilitarios más ergonómicos que aceptan una función callback como child.
  • Actualizar el formato de salida del CLI, especialmente en el reporte de errores.
  • Actualiza @astrojs/compiler, corrigiendo algunos bugs relacionados con el uso de RegExp en frontmatter

La configuración de renderers ha sido reemplazada por un nuevo sistema oficial de integraciones! Esto desbloquea algunas funcionalidades nuevas realmente emocionantes para Astro. Puedes leer nuestra guía Usando Integraciones para más detalles sobre cómo usar este nuevo sistema.

Las integraciones reemplazan nuestro concepto original de renderers, y vienen con algunos cambios importantes y nuevos valores por defecto para usuarios existentes. Estos cambios se cubren a continuación.

Anteriormente, React, Preact, Svelte, y Vue venían incluidos con Astro por defecto. A partir de v0.25.0, Astro ya no viene con ningún renderer integrado. Si no tenías una entrada de configuración de renderers ya definida para tu proyecto, ahora necesitarás instalar esos frameworks tú mismo.

Lee nuestro recorrido paso a paso para aprender cómo añadir una nueva integración de Astro para el/los framework(s) que usas actualmente.

El nuevo sistema de integraciones reemplaza el sistema anterior de renderers, incluyendo los paquetes publicados @astrojs/renderer-* en npm. De ahora en adelante, @astrojs/renderer-react pasa a ser @astrojs/react, @astrojs/renderer-vue pasa a ser @astrojs/vue, y así sucesivamente.

Para migrar: actualiza Astro a v0.25.0 y luego ejecuta astro dev o astro build con tu archivo de configuración anterior que contiene la configuración obsoleta de "renderers". Inmediatamente verás un aviso indicándote los cambios exactos que necesitas hacer en tu archivo astro.config.mjs, basado en tu configuración actual. También puedes actualizar tus paquetes tú mismo, usando la tabla a continuación.

Para un recorrido más detallado, lee nuestra guía paso a paso para aprender cómo reemplazar renderers existentes con una nueva integración de framework de Astro.

Ventana de la terminal
# Install your new integrations and frameworks:
# (Read the full walkthrough: https://docs.astro.build/en/guides/integrations-guide)
npm install @astrojs/lit lit
npm install @astrojs/react react react-dom
// Then, update your `astro.config.mjs` file:
// (Read the full walkthrough: https://docs.astro.build/en/guides/integrations-guide)
import lit from '@astrojs/lit';
import react from '@astrojs/react';
export default {
renderers: ['@astrojs/renderer-lit', '@astrojs/renderer-react'],
integrations: [lit(), react()],
}
Renderers deprecados en npm Integraciones v0.25+ en npm
@astrojs/renderer-react @astrojs/react
@astrojs/renderer-preact @astrojs/preact
@astrojs/renderer-solid @astrojs/solid-js
@astrojs/renderer-vue @astrojs/vue
@astrojs/renderer-svelte @astrojs/svelte

A diferencia de los renderers anteriores, las integraciones ya no marcan los frameworks mismos ("react", "svelte", "vue", etc.) como dependencias directas de la integración. En su lugar, ahora debes instalar los paquetes de tu framework además de tus integraciones.

Ventana de la terminal
# Example: Install integrations and frameworks together
npm install @astrojs/react react react-dom

Si ves una advertencia "Cannot find package 'react'" (o similar) al iniciar Astro, significa que necesitas instalar ese paquete en tu proyecto. Consulta nuestra nota sobre peer dependencies en la guía de troubleshooting para más información.

Si estás usando npm y Node v16+, esto puede ser manejado automáticamente por npm, ya que la última versión de npm (v7+) instala peer dependencies como esta automáticamente. En ese caso, instalar un framework como "react" en tu proyecto es un paso opcional pero aún recomendado.

Nos encanta encontrar valores por defecto sensatos que "simplemente funcionan" out-of-the-box. Como parte de esto, decidimos hacer de Shiki nuestro nuevo resaltador de sintaxis por defecto. Este viene pre-configurado con el tema github-dark, proporcionando resaltado sin configuración en tus bloques de código sin clases CSS extraneous, hojas de estilo, ni JS del lado del cliente.

Consulta nuestra nueva documentación de resaltado de sintaxis para todos los detalles. Si prefieres mantener Prism como tu resaltador de sintaxis, establece la opción syntaxHighlight a 'prism' en la configuración de markdown de tu proyecto.

Como parte de nuestra misión de mantener el núcleo de Astro lo más ligero posible, hemos movido el componente integrado Prism de astro/components al paquete @astrojs/prism. Ahora puedes importar este componente desde @astrojs/prism así:

---
import { Prism } from '@astrojs/prism';
---

Dado que el paquete @astrojs/prism aún viene incluido con el núcleo de astro, no necesitarás instalar nada nuevo, ni añadir Prism como integración! Sin embargo, ten en cuenta que planeamos extraer @astrojs/prism (y el resaltado de sintaxis de Prism en general) a un paquete separado instalable en el futuro. Consulta la referencia de la API del componente <Prism /> para más detalles.

Nuestro parser de CSS interno ha sido actualizado, y viene con mejor soporte para sintaxis CSS avanzada, como container queries. Esto debería ser un cambio mayormente invisible para la mayoría de usuarios, pero esperamos que los usuarios avanzados disfruten del nuevo soporte de funcionalidades CSS.

0.24 introdujo una nueva estrategia de static build que cambia el comportamiento de algunas funcionalidades. En versiones anteriores de Astro esto era un comportamiento disponible con un flag opt-in: --experimental-static-build.

Para migrar la transición, ten en cuenta los siguientes cambios que serán necesarios para moverte a este nuevo motor de build. Puedes hacer estos cambios en tu código base en cualquier momento para estar listo con anticipación.

Astro.resolve() te permite obtener URLs resueltas a assets que podrías querer referenciar en el navegador. Esto se usaba más comúnmente dentro de etiquetas <link> y <img> para cargar archivos CSS e imágenes según fuera necesario. Desafortunadamente, esto ya no funcionará debido a que Astro ahora construye los assets en tiempo de build en lugar de en tiempo de renderizado. Querrás actualizar tus referencias de assets a una de las siguientes opciones a prueba de futuro disponibles de ahora en adelante:

1. ESM Import (Recommended)

Ejemplo: import './style.css'; Cuándo usar esto: Si tu archivo CSS vive dentro del directorio src/, y quieres las funcionalidades automáticas de build y optimización de CSS.

Usa una importación ESM para añadir algo de CSS a la página. Astro detecta estas importaciones CSS y luego construye, optimiza, y añade el CSS a la página automáticamente. Esta es la forma más fácil de migrar desde Astro.resolve() manteniendo el building/bundling automático que Astro proporciona.

---
// Example: Astro will include and optimize this CSS for you automatically
import './style.css';
---
<html><!-- Your page here --></html>

Importar archivos CSS debería funcionar en cualquier lugar donde se soporten importaciones ESM, incluyendo:

  • Archivos JavaScript
  • Archivos TypeScript
  • Frontmatter de componentes de Astro
  • Componentes no-Astro como React, Svelte, y otros

Cuando un archivo CSS se importa usando este método, cualquier statement @import también se resuelve e inlinea en el archivo CSS importado. Todas las referencias url() también se resuelven relativas al archivo fuente, y cualquier asset referenciado por url() se incluirá en el build final.

2. Absolute URL Path

Ejemplo: <link href="/style.css"> Cuándo usar esto: Si tu archivo CSS vive dentro de public/, y prefieres crear tu elemento HTML link tú mismo.

Puedes referenciar cualquier archivo dentro del directorio public/ por ruta URL absoluta en la plantilla de tu componente. Esta es una buena opción si quieres controlar la etiqueta <link> en la página tú mismo. Sin embargo, este enfoque también omite el procesamiento de CSS, bundling y optimizaciones que proporciona Astro cuando usas el método import descrito anteriormente.

Recomendamos usar el enfoque de import sobre el enfoque de URL absoluta ya que proporciona el mejor rendimiento y funcionalidades CSS posibles por defecto.

1. Absolute URL Path

Ejemplo: <script src="/some-external-script.js" /> Cuándo usar esto: Si tu archivo JavaScript vive dentro de public/.

Puedes referenciar cualquier archivo dentro del directorio public/ por ruta URL absoluta en las plantillas de tus componentes de Astro. Esta es una buena opción por defecto para scripts externos porque te permite controlar la etiqueta <script> en la página tú mismo.

Ten en cuenta que este enfoque omite el procesamiento de JavaScript, bundling y optimizaciones que proporciona Astro cuando usas el método import descrito a continuación. Sin embargo, esto puede ser preferible para cualquier script externo que ya haya sido publicado y minificado por separado de Astro. Si tu script fue descargado de una fuente externa, entonces este método es probablemente el preferido.

2. ESM Import via <script hoist>

Ejemplo: <script hoist>import './some-external-script.js';</script> Cuándo usar esto: Si tu script externo vive dentro de src/ y soporta el tipo de módulo ESM.

Usa una importación ESM dentro de un elemento <script hoist> en tu plantilla de Astro, y Astro incluirá el archivo JavaScript en tu build final. Astro detecta estas importaciones JavaScript del lado del cliente y luego construye, optimiza, y añade el JavaScript a la página automáticamente. Esta es la forma más fácil de migrar desde Astro.resolve() manteniendo el building/bundling automático que Astro proporciona.

<script hoist>
import './some-external-script.js';
</script>

Ten en cuenta que Astro empaquetará este script externo con el resto de tu JavaScript del lado del cliente, y lo cargará en el contexto de script type="module". Algunos archivos JavaScript antiguos pueden no estar escritos para el contexto module, en cuyo caso pueden necesitar ser actualizados para usar este método.

1. Absolute URL Path (Recommended)

Ejemplo: <img src="/penguin.png"> Cuándo usar esto: Si tu asset vive dentro de public/.

Si colocas tus imágenes dentro de public/ puedes referenciarlas de forma segura por ruta URL absoluta directamente en las plantillas de tus componentes. Esta es la forma más simple de referenciar un asset que puedes usar hoy, y es recomendada para la mayoría de usuarios que están empezando con Astro.

2. ESM Import

Ejemplo: import imgUrl from './penguin.png' Cuándo usar esto: Si tu asset vive dentro del directorio src/, y quieres funcionalidades de optimización automática como hash de nombre de archivo.

Esto funciona dentro de cualquier componente JavaScript o Astro, y devuelve una URL resuelta a la imagen final. Una vez que tienes la URL resuelta, puedes usarla en cualquier lugar dentro de la plantilla del componente.

---
// Example: Astro will include this image file in your final build
import imgUrl from './penguin.png';
---
<img src={imgUrl} />

Similar a cómo Astro maneja CSS, la importación ESM permite a Astro realizar algunas optimizaciones de build simples automáticamente. Por ejemplo, cualquier asset dentro de src/ que se importe usando una importación ESM (ej: import imgUrl from './penguin.png') tendrá su nombre de archivo hasheado automáticamente. Esto te permite cachear el archivo más agresivamente en el servidor, mejorando el rendimiento del usuario. En el futuro, Astro puede añadir más optimizaciones como esta.

Consejo: Si no te gustan las importaciones ESM estáticas, Astro también soporta importaciones ESM dinámicas. Solo recomendamos esta opción si prefieres esta sintaxis: <img src={(await import('./penguin.png')).default} />.

Deprecado: Procesamiento por defecto de <script>

Sección titulada “Deprecado: Procesamiento por defecto de <script>”

Anteriormente, todos los elementos <script> se leían desde la salida HTML final y se procesaban + empaquetaban automáticamente. Este comportamiento ya no es el predeterminado. A partir de 0.24, debes optar por el procesamiento de elementos <script> a través del atributo hoist. El type="module" también es obligatorio para los módulos hoisted.

<script>
// Will be rendered into the HTML exactly as written!
// ESM imports will not be resolved relative to the file.
</script>
<script type="module" hoist>
// Processed! Bundled! ESM imports work, even to npm packages.
</script>
Preprocessor dependency "sass" not found. Did you install it?

En nuestra misión de reducir el tamaño de instalación de npm, hemos movido Sass a una dependencia opcional. Si usas Sass en tu proyecto, querrás asegúrate de ejecutar npm install sass --save-dev para guardarlo como dependencia.

En Astro v0.23+, el contenido HTML sin escapar en expresiones ahora está deprecado. En futuros releases, el contenido dentro de expresiones tendrá las strings escapadas para proteger contra inyección de HTML no intencionada.

<h1>{title}</h1> <!-- <h1>Hello <strong>World</strong></h1> -->
<h1>{title}</h1> <!-- <h1>Hello &lt;strong&gt;World&lt;/strong&gt;</h1> -->

Para continuar inyectando HTML sin escapar, ahora puedes usar set:html.

<h1>{title}</h1>
<h1 set:html={title} />

Para evitar un elemento contenedor, set:html puede funcionar junto con <Fragment>.

<h1>{title}!</h1>
<h1><Fragment set:html={title}>!</h1>

También puedes protegerte contra la inyección de HTML no intencionada con set:text.

<h1 set:text={title} /> <!-- <h1>Hello &lt;strong&gt;World&lt;/strong&gt;</h1> -->

A partir de v0.21, Astro está construido con Vite. Como resultado, las configuraciones escritas en snowpack.config.mjs deberían moverse a astro.config.mjs.

// @ts-check
/** @type {import('astro').AstroUserConfig} */
export default {
renderers: [],
vite: {
plugins: [],
},
};

Para aprender más sobre cómo configurar Vite, visita su guía de configuración.

En Astro v0.21+, los plugins de Vite pueden configurarse dentro de astro.config.mjs.

import { imagetools } from 'vite-imagetools';
export default {
vite: {
plugins: [imagetools()],
},
};

Para aprender más sobre los plugins de Vite, visita su guía de plugins.

En Astro v0.21+, los plugins ahora deberían usar viteConfig().

renderer-svelte/index.js
import { svelte } from '@sveltejs/vite-plugin-svelte';
export default {
name: '@astrojs/renderer-svelte',
client: './client.js',
server: './server.js',
snowpackPlugin: '@snowpack/plugin-svelte',
snowpackPluginOptions: { compilerOptions: { hydratable: true } },
viteConfig() {
return {
optimizeDeps: {
include: ['@astrojs/renderer-svelte/client.js', 'svelte', 'svelte/internal'],
exclude: ['@astrojs/renderer-svelte/server.js'],
},
plugins: [
svelte({
emitCss: true,
compilerOptions: { hydratable: true },
}),
],
};
},
}

Para aprender más sobre los plugins de Vite, visita su guía de plugins.

En Astro v0.21+, los aliases de importación pueden añadirse en tsconfig.json.

{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/components/*": ["src/components/*"]
}
}
}

En Astro v0.21+, los archivos necesitan ser referenciados por su extensión actual, exactamente como está en disco. En este ejemplo, Div.tsx necesitaría ser referenciado como Div.tsx, no como Div.jsx.

import Div from './Div.jsx' // Astro v0.20
import Div from './Div.tsx' // Astro v0.21

Este mismo cambio aplica a un archivo compile-to-css como Div.scss:

<link rel="stylesheet" href={Astro.resolve('./Div.css')}>
<link rel="stylesheet" href={Astro.resolve('./Div.scss')}>

Anteriormente, podías crear mini Componentes de Astro dentro del Frontmatter de Astro, usando sintaxis JSX en lugar de la sintaxis de componentes de Astro. Esto siempre fue un poco un hack, pero en el nuevo compilador se hizo imposible de soportar. Esperamos re-introducir esta funcionalidad en un futuro release de Astro usando una API diferente, no-JSX.

Para migrar a v0.21+, por favor convierte todos los componentes JSX de Astro (es decir, cualquier componente de Astro creado dentro del frontmatter de otro componente) a componentes independientes.

Autoprefixer ya no se ejecuta por defecto. Para habilitarlo:

  1. Instala la última versión (npm install autoprefixer)

  2. Crea un archivo postcss.config.cjs en la raíz de tu proyecto con:

    module.exports = {
    plugins: {
    autoprefixer: {},
    },
    };

Asegúrate de tener PostCSS instalado. Esto era opcional en versiones anteriores, pero ahora es obligatorio:

  1. Instala la última versión de postcss (npm install -D postcss)

  2. Crea un archivo postcss.config.cjs en la raíz de tu proyecto con:

    module.exports = {
    plugins: {
    tailwindcss: {},
    },
    };

    Para más información, lee la documentación de Tailwind CSS

En Astro v0.21+, se ha introducido un bug que requiere que las importaciones dentro de componentes estén al inicio de tu frontmatter.

---
import Component from '../components/Component.astro'
const whereShouldIPutMyImports = "on top!"
---
Contribuir Comunidad Patrocinar