Astro 7.0

¡Astro 7 está aquí! Este lanzamiento va todo sobre velocidad. El compiler de .astro ha sido reescrito en Rust. El procesamiento de Markdown y MDX ahora se ejecuta a través de un nuevo pipeline potenciado por Rust. El rendering engine ha sido reemplazado por un enfoque basado en colas más rápido. Junto con Vite 8 y su nuevo bundler Rolldown, los builds de Astro 7 son 15-61% más rápidos en nuestros benchmarks. El build más rápido es el que no ocurre en absoluto, así que Astro 7 también estabiliza el route caching y añade CDN cache providers experimentales para Netlify, Vercel, y Cloudflare.

Astro 7 también introduce Advanced Routing, dándote un entrypoint src/fetch.ts con control total sobre el pipeline de peticiones de Astro. Para el desarrollo asistido por IA, Astro ahora puede detectar coding agents, ejecutar el dev server en segundo plano, y emitir logs JSON estructurados cuando los agents necesitan feedback machine-readable.

Los aspectos destacados completos del lanzamiento incluyen:

• Vite 8
• Rendimiento
  • Rust Compiler
  • Markdown & MDX in Rust
  • Queued Rendering
• Advanced Routing
• Route Caching
  • CDN Cache Providers
• AI Enhancements
  • Background Dev Server
  • JSON Logging
• Comunidad

Actualiza ahora

Para actualizar un proyecto existente a Astro 7, usa la herramienta CLI automatizada @astrojs/upgrade:

# Recommended:
npx @astrojs/upgrade

# Manual:
npm install astro@latest

Para nuevos proyectos, simplemente usa:

npm create astro@latest

Consulta la guía de actualización para pasos detallados de migración.

Vite 8

Astro 7 actualiza a Vite 8, el lanzamiento más significativo de Vite en años. El cambio principal: Vite ahora incluye Rolldown, un bundler basado en Rust que reemplaza tanto a esbuild como a Rollup con un único bundler unificado. Rolldown es 10-30x más rápido que Rollup en benchmarks mientras soporta las mismas APIs de plugins de Rollup y Vite.

Para los usuarios de Astro, esto significa builds más rápidos sin cambios de configuración para la mayoría de proyectos. Vite 8 incluye una capa de compatibilidad que auto-convierte la configuración existente de esbuild y rollupOptions a sus equivalentes en Rolldown. Si tu proyecto usa plugins personalizados de Vite, la mayoría deberían seguir funcionando porque Rolldown soporta la misma API de plugins que Rollup.

Rendimiento

Astro 7 es la versión más rápida de Astro hasta la fecha. A medida que el uso ha crecido, más equipos han estado empujando los límites de qué tipo de sitio se puede construir con Astro. Después de lanzar Astro 6 y su gran refactor interno, pusimos nuestra mira en ayudar a Astro a escalar a sitios más grandes y complejos.

Así es como funcionan los builds de Astro:

1. Agrupar las páginas del sitio, el contenido, y los componentes de cliente en JavaScript.
2. Ejecutar el código agrupado como un pequeño server, crear peticiones para cada página prerenderizada, y guardar el HTML resultante.

Astro 7 mejora ambos pasos, pero se enfoca en el primero: agrupar el sitio. Las mayores ganancias vienen de mover algunas de las partes más lentas del build a código nativo escrito en Rust. El paso de generación también es más rápido, gracias a una nueva estrategia de renderizado que hace colas de secciones a renderizar de forma más efectiva.

En nuestras pruebas, los tiempos de build generales mejoraron en un 15–61%, con algunos sitios compilando más de dos veces más rápido. Los sitios donde la compilación de .astro y el procesamiento de Markdown representan una mayor parte del build ven las mayores ganancias, ya que esas son exactamente las partes que se movieron a Rust.

Estos benchmarks se ejecutaron en un MacBook Pro Apple M4 Pro con 48 GB de memoria:

Rust Compiler

Construimos un nuevo compiler para el formato de componentes .astro, ahora escrito en Rust. El compiler es una reescritura completa de nuestro compiler anterior basado en Go que es mayormente backwards compatible, excepto por:

• No más corrección de HTML. El compiler de Go reescribía silenciosamente tu markup para ser "HTML válido" reordenando elementos, auto-cerrando etiquetas, y moviendo nodos de formas que a menudo sorprendían a los usuarios y causaban problemas difíciles de debuggear. El nuevo compiler trata tu markup tal cual.
• Strictness estilo JSX. Etiquetas no cerradas como <div>Hello y atributos no terminados como <div class="Hello > ahora producen errores en lugar de ser corregidos silenciosamente. Estos son bugs reales en plantillas que el compiler antiguo ignoraba silenciosamente en un intento de comportarse como el browser.
• JSX whitespace handling. Whitespace between elements is now collapsed following JSX conventions, matching the behavior of React and other JSX-based frameworks. For example, newlines between inline elements no longer produce a visible space:

  <!-- Before: renders as "Hello World" (with a space) -->
  <!-- After: renders as "HelloWorld" (no space) -->
  <span>Hello</span>
  <span>World</span>
  
  <!-- To preserve the space, use an explicit expression: -->
  <span>Hello</span>{' '}<span>World</span>

Moverse a Rust nos permitió incluir binarios nativos para las plataformas soportadas, con un fallback WASM para entornos que lo necesitan. Este patrón ahora es estándar en el mundo de tooling de JavaScript, usado por proyectos como Rolldown y Lightning CSS. Por debajo, el nuevo compiler está construido sobre oxc para parsing y Lightning CSS para CSS scoping.

De forma aislada, el compiler de Rust mostró una mejora de aproximadamente 6% en los tiempos de build en https://docs.astro.build. Eso es porque la compilación de .astro rara vez es el bottleneck; el procesamiento de Markdown y el bundling típicamente dominan el tiempo de build. Pero cada bit se suma, especialmente en sitios grandes con miles de páginas, y las ganancias del compiler se acumulan con las otras mejoras de rendimiento de este lanzamiento.

Markdown & MDX in Rust

Astro 7 reemplaza el pipeline por defecto de Markdown y MDX con Sätteri, un procesador potenciado por Rust creado por el miembro del core team de Astro Erika . Cambiar los builds de la documentación de Astro y Cloudflare a Sätteri recortó más de un minuto de sus tiempos de build, haciendo que los sitios pesados en Markdown sean los mayores ganadores de Astro 7.

Hasta ahora, el pipeline de Markdown de Astro se ejecutaba en unified (remark, rehype, y una larga cola de dependencias de JavaScript). En sitios grandes con miles de páginas, ese pipeline era a menudo la fase más lenta del build: cada archivo se parseaba a través de JavaScript, se ejecutaba a través de plugin tras plugin sobre el AST completo, luego se serializaba de vuelta a HTML. En Astro 6.4, hicimos el pipeline conectable e incluimos Sätteri como una alternativa opt-in. Astro 7 lo hace el default.

Por debajo, Sätteri usa pulldown-cmark para parsing de CommonMark y Oxc para parsing de expresiones MDX, ambos nativos de Rust. Incluye binarios específicos por plataforma con un fallback WASM, el mismo enfoque usado por el nuevo compiler de .astro. La velocidad no es la única ganancia, sin embargo. Sätteri también implementa muchas características de Markdown nativamente que previamente requerían plugins separados:

Las características no por defecto se habilitan a través de la opción features:

import { defineConfig } from 'astro/config';
import { satteri } from '@astrojs/markdown-satteri';

export default defineConfig({
  markdown: {
    processor: satteri({
      features: {
        directive: true,
        math: true,
        headingAttributes: true,
      },
    }),
  },
});

Sätteri tiene su propia API de plugins también. Los plugins declaran qué tipos de nodos les importan y saltan el resto, en lugar de recorrer todo el árbol en cada pasada. Esto hace que añadir plugins sea mucho más barato que en unified, donde cada plugin recorre cada nodo.

Si dependes de plugins de remark o rehype, el pipeline basado en unified sigue disponible vía @astrojs/markdown-remark:

import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';
import remarkToc from 'remark-toc';

export default defineConfig({
  markdown: {
    processor: unified({
      remarkPlugins: [remarkToc],
    }),
  },
});

Aprende más sobre las características de Sätteri y su API de plugins en satteri.bruits.org.

Queued Rendering

Queued rendering fue introducido en Astro 6.0 como una opción experimental y ahora es estable y el rendering engine por defecto. ¡Es ~2.4× más rápido¹ en velocidad!

import { defineConfig } from "astro/config";

export default defineConfig({
  experimental: {
    queuedRendering: {
      enabled: true,
      pooling: true,
      contentCache: 1000
    }
  }
})

Previamente, Astro renderizaba páginas usando un enfoque recursivo donde los hijos se renderizaban usando la misma función render*, como en el siguiente pseudocódigo:

export function renderComponentToString(node: unknown): string {
  let destination = "";
  destination += `<${node.name}>`; // opening tag

  // render attributes

  for (const child of node.children) {
    // Here's where we recurse the children by calling renderComponentToString
    destination += renderComponentToString(child);
  }

  destination += `</${node.name}>`; // closing tag

  return destination;
}

El nuevo engine usa una cola (o stack) y un único loop. La cola se llena con nodos hijos en el orden correcto, y el loop sigue renderizando nodos hasta que la cola se vacía. El siguiente pseudocódigo es una versión oversimplificada del real, pero debería dar una imagen clara:

export function renderComponentToString(root: unknown): string {
  let destination = "";
  destination += `<${root.name}>`; // opening tag

  // this is our queue, populated and flushed as we render
  let stack = [root];

  while (stack.length > 0) {
    const node = stack.pop();

    if (Array.isArray(node)) {
      // The nodes at the very end must be rendered to destination first
      for (let i = node.length - 1; i >= 0; i--) stack.push(node[i]);
      continue;
    }

    const nodeType = typeof node;
    if (nodeType === 'string') {
      destination += escapeHTML(node as string);
    }
  }
  destination += `</${root.name}>`; // opening tag
  return destination;
}

La primera implementación de la estrategia funcionaba en una fase de dos pasadas: crear una lista ordenada de componentes (nodos), y recorrer la lista y renderizar los componentes.

La nueva implementación ya no crea una lista completa, en su lugar la lista se renderiza (se vacía) mientras se recorre. Este enfoque final es más rápido que la primera iteración, y necesita menos memoria comparado con el enfoque recursivo.

Advanced Routing

Astro empezó como un static site generator con file-based routing. Con el tiempo, características como middleware, redirects, rewrites, Actions, sessions, e i18n dieron a las apps de Astro más poder del lado del servidor, pero también hicieron el ciclo de vida de las peticiones más difícil de controlar. Si necesitabas que auth se ejecutara antes de Actions, que logging envolviera solo el renderizado de páginas, o que una API no-Astro manejara algunas peticiones primero, tenías que trabajar alrededor del pipeline en lugar de componerlo directamente.

En Astro 7, ahora puedes tomar control total sobre el pipeline de peticiones de Astro añadiendo un archivo src/fetch.ts a tu proyecto. Este archivo exporta el patrón estándar de handler fetch popularizado por Cloudflare Workers, Deno, y Bun.

import { astro, FetchState } from 'astro/fetch';

export default {
  fetch(request: Request) {
    const state = new FetchState(request);

    // Forward API requests to a backend service
    if (state.url.pathname.startsWith('/api')) {
      const url = new URL(state.url.pathname + state.url.search, 'https://backend-api.example.com');
      return fetch(new Request(url, request));
    }

    // Fallback to Astro pages/endpoints
    return astro(state);
  }
}

La API también es compatible con Hono, permitiéndote traer Hono middleware a tu aplicación de Astro:

import { astro } from 'astro/hono';
import { Hono } from 'hono';
import { basicAuth } from 'hono/basic-auth';

const app = new Hono();
app.use(basicAuth({ username: 'admin', password: 'secret' }));
app.use(astro());

export default app;

Para uso avanzado, puedes componer características individuales de Astro como middleware separado, dándote control total sobre el pipeline de peticiones. Si alguna vez has usado Astro middleware y te ha frustrado que tu check de auth se ejecutara después de Astro Actions, o que no podías loguear el timing de respuesta sin envolver todo tú mismo, ahora puedes poner tu código exactamente donde necesita estar:

import { Hono } from 'hono';
import { actions, middleware, pages, i18n } from 'astro/hono';
import { auth } from './middleware/auth';
import { timing } from './middleware/timing';

const app = new Hono();

app.use(i18n());
app.use(auth());       // Auth runs before actions, no unauthenticated calls
app.use(actions());
app.use(middleware());
app.use(timing());     // Timing wraps only page rendering
app.use(pages());

export default app;

Si no añades un archivo src/fetch.ts, Astro se comporta exactamente como lo hace hoy.

Route Caching

Cachear respuestas on-demand rendered es más difícil de lo que debería ser. Cada host lo hace diferente, y nunca ha habido una forma estándar de controlarlo desde el código de tu aplicación. Astro 7 introduce route caching para solucionar esto. Lanzado por primera vez experimentalmente en Astro 6, la característica ahora es estable y añade una sola API platform-agnostic para caching: establece directivas en tus rutas, y Astro maneja el resto sin importar dónde despliegas.

Configuras un cache provider una vez, luego usas Astro.cache en tus páginas (o context.cache en API routes y middleware) para controlar el caching por respuesta, basado en semánticas estándar de HTTP caching. Astro incluye un provider memoryCache() integrado para que empieces:

import { defineConfig, memoryCache } from 'astro/config';

export default defineConfig({
  cache: {
    provider: memoryCache(),
  },
});

---
Astro.cache.set({
  maxAge: 120, // Cache for 2 minutes
  swr: 60, // Serve stale for 1 minute while revalidating
  tags: ['products'], // Tag for targeted invalidation
});
---

También puedes definir reglas de caching para grupos de rutas declarativamente en tu configuración con routeRules, manteniendo el caching fuera de tu código de rutas enteramente:

export default defineConfig({
  cache: { provider: memoryCache() },
  routeRules: {
    '/blog/[...path]': { maxAge: 300, swr: 60 },
  },
});

Donde el route caching realmente brilla es en su integración con live content collections. Un live loader puede adjuntar un cache hint a los datos que devuelve, con tags para invalidación y un last-modified time para frescura. Pasa ese entry directamente a Astro.cache.set() y Astro lee el hint por ti, sin headers manuales requeridos:

---
import { getLiveEntry } from 'astro:content';
const { entry } = await getLiveEntry('products', Astro.params.id);

// Astro reads the loader's cache hint from the entry:
Astro.cache.set(entry);
---

Las respuestas cacheadas pueden purgarse on demand con cache.invalidate(), por tag o por path. Por ejemplo, puedes exponer un webhook endpoint para que tu CMS lo llame cuando el contenido cambie. Esto se mapea a la API de invalidación de cada provider, limpiando cada respuesta afectada sin un rebuild:

import type { APIRoute } from 'astro';

export const POST: APIRoute = async ({ request, cache }) => {
  // A real implementation would validate the request and check a secret token before invalidating.

  const { slug } = await request.json();

  // Invalidate every response tagged 'products'...
  await cache.invalidate({ tags: ["products"] });

  // ...invalidate every page that used a particular entry...
  await cache.invalidate({ tags: [`products:${slug}`] });

  // ...or purge a single path directly.
  await cache.invalidate({ path: `/products/${slug}` });

  return new Response('Revalidated');
};

Si probaste el route caching mientras era experimental, el único cambio es mover cache y routeRules fuera del bloque experimental al nivel superior de tu configuración. La API por lo demás no cambia. Consulta la guía de route caching para la referencia completa.

CDN Cache Providers

Cuando el route caching se lanzó en Astro 6, venía con un único provider in-memory para usar con el adaptador de Node. Astro 7 añade CDN providers experimentales para Netlify, Vercel, y Cloudflare (en private beta).

En lugar de almacenar respuestas en memoria, estos providers empujan tus directivas de caching hacia la edge network del host, para respuestas aún más rápidas. Los cache hits se sirven directamente desde el CDN, sin invocar tu server function en absoluto.

En un futuro lanzamiento, estos providers se habilitarán automáticamente, pero durante la fase experimental deberías añadirlos manualmente. Importa el provider para tu adaptador y configúralo como tu cache provider:

import { defineConfig } from 'astro/config';
import netlify from '@astrojs/netlify';
import { cacheNetlify } from '@astrojs/netlify/cache';

export default defineConfig({
  adapter: netlify(),
  cache: {
    provider: cacheNetlify(),
  },
});

Cada adaptador exporta un provider desde su entrypoint /cache:

Las mismas APIs Astro.cache, routeRules, y cache.invalidate() funcionan con cada provider. Cada uno traduce tus directivas a los headers nativos de cache-control de la plataforma y purgas basadas en tags o paths.

AI Enhancements

Los AI coding agents ahora son parte del workflow de muchos desarrolladores, y necesitan cosas diferentes de un dev server que los humanos. Astro 7 es nuestro primer paso hacia hacer de Astro una mejor plataforma para el desarrollo dirigido por agents.

Background Dev Server

Los AI agents luchan con procesos de larga duración. Hacen shell out, esperan al exit, y leen la salida, pero un dev server nunca termina. Los agents se cuelgan, arrancan servidores duplicados, pierden el rastro de instancias en ejecución, o dejan procesos zombie atrás. Vemos esto como parte del automated issue triage de Astro también, con agents a veces gastando más tiempo peleando con dev servers que testeando código.

Astro 7 añade astro dev --background, que arranca el dev server como un proceso en segundo plano gestionado. Astro también puede detectar cuando se está ejecutando dentro de un AI agent y habilitar el modo background automáticamente, así no se necesitan flags en los workflows de agents. Si no se detecta ningún agent, astro dev se comporta exactamente como antes.

$ astro dev --background
Dev server running at http://localhost:4321 (pid 12345)
  Stop:   astro dev stop
  Status: astro dev status
  Logs:   astro dev logs

El comando bloquea hasta que el server está listo para aceptar peticiones, reporta el URL y el process ID, luego se desvincula. No hay polling, no hay sleeping, no hay parsing de salida de terminal buscando "Local:".

Un lockfile previene instancias duplicadas. Si un agent intenta arrancar un segundo server, obtiene los detalles de la instancia existente en lugar de spawnear un proceso conflictivo:

$ astro dev --background
Dev server already running at http://localhost:4321 (pid 12345)

Puedes comprobar el estado y parar el server desde sesiones de shell separadas:

$ astro dev status
Dev server running at http://localhost:4321 (pid 12345, uptime 123s, background)

$ astro dev stop
Stopped dev server (pid 12345).

También puedes leer los logs del background server con astro dev logs.

Cada comando es idempotente y tolerante. Parar cuando no está corriendo tiene éxito silenciosamente, y arrancar cuando ya está corriendo devuelve la instancia existente. Los agents a menudo pierden el rastro del estado del proceso, y la CLI no los castiga por ello.

Todos los dev servers en ejecución también exponen un health endpoint /_astro/status que los agents pueden consultar para confirmar que el server está vivo y listo para aceptar peticiones.

JSON Logging

El logger de Astro ahora es totalmente configurable. Para los agents, el JSON logging se habilita automáticamente cuando la detección de agents activa el modo background. Para todos los demás, está disponible vía CLI o configuración:

astro dev --json

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

export default defineConfig({
  logger: logHandlers.json()
})

El JSON logging fue la solicitud de característica más votada en nuestra roadmap, y no solo por la IA. Los equipos que despliegan Astro SSR a producción necesitan logs estructurados para la integración con servicios de log aggregation como Kibana, CloudWatch, y Grafana/Loki. El logging anterior de Astro estaba hardcoded para legibilidad humana: colores, caracteres de box-drawing, formato de errores multi-línea. Nada de eso es parseable por máquinas.

La nueva logger API también soporta custom log handlers y una API compose() para combinar múltiples loggers. Por ejemplo, puedes mantener salida human-readable en la consola mientras también escribes logs JSON para herramientas que necesitan salida estructurada:

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

export default defineConfig({
  logger: logHandlers.compose(
    logHandlers.console(),
    logHandlers.json()
  )
})

Aprende más sobre el soporte de Astro para tooling de IA en la guía de IA.

Comunidad

El core team de Astro es:

Alexander Niebuhr , Armand Philippot , Chris Swithinbank , Emanuele Stoppa , Erika , Florian Lefebvre , Fred Schott , HiDeoo , Luiz Ferraz , Matt Kane , Matthew Phillips , Reuben Tier , Sarah Rainsberger , and Yan Thomas .

Agradecimiento especial a todos los que contribuyeron a Astro 7 con código, documentación, revisiones, y testing, incluyendo:

0x K., 0xRozier, AceCodePt, Adam Chalemian, Adam Matthiesen, Adam McKee, Adam Page, Agus Setiawan, Ahmad Yasser, Alejandro Romano, Alex, Alex Dombroski, Alex Launi, Alexander Flodin, Alexis Aguilar, Aly Cerruti, Amar Reddy, Andreas Deininger, Andrei Alba, Antony Faris, Ariel K, Ash Hitchcock, atsbob, B Sai Thrishul, Barry, Ben Limmer, Bernd Strehl, BitToby, btea, Burra Karthikeya, buschtrisha77, Calvin Liang, Cameron Pak, Cameron Smith, Carlos Lázaro Costa, chaegumi, Chan, Chase McCoy, ChrisLaRocque, Ciaran Moran, Corbin Crutchley, CyberFlame, Daniel Bodky, Daniel Lo Nigro, Daniel Zamyatin, Daniil Sivak, Dario Piotrowicz, dataCenter430, Dawid Gaweł, Desel72, dfedoryshchev, Dom Christie, done, Dor Alagem, Dream, Ed Melly, Ed Melly, Edgar, Ellie, Em Poulter, Eric Grill, Eric Mika, Eryk Baran, Eveeifyeve, fabon, farshad, Felipe Arce, Felix Schneider, Felmon, fkatsuhiro, G Taki@MAX, Giray, Gokhan Kurt, Great Journey, Greg L. Turnquist, Harsh Agarwal, Haz, helio-cf, Henri Fournier, Henri Koskenranta, Henry, Igor Koop, Jack Lukic, Jack Moorhouse, Jack Shelton, jahndan, James Basoo, James Garbutt, James Murty, James Opstad, Jason P. Cochrane, Jett Way, Jimmy, joel hansson, John Mortlock, Johnny Noble, Jon Ege Ronnenberg, Joost de Valk, Jordan Demaison, Josh Soref, JPette1783, Julian Wolf, Julien Cayzac, Junseong Park, Justin Francos, Kai, kato takeshi, Kedar Vartak, Kendell, Kevin Brown, knj, Koji Wakamiya, Konrad Szajna, Kristijan, KTrain, Kumar Gautam, Kyle McLean, Lee Freeman, Leif Marcus, Leonie, Lieke, liruifengv, LongYC, Louis Escher, Luke Deen Taylor, MA2153, Mark Ignacio, Martin DONADIEU, Martin Heidegger, Martin Trapp, Matheus Baroni, Mathieu Mafille, Matthew Justice, Matthias, Matthieu Tremblay, Mavik, Max Malkin, maxim, meyer, Michael Giraldo, Mike Pagé, Milo, Minh Lê, Misrilal, MkDev11, Mochammad Farros Fatchur Roji, moktamd, Naren, Natan Sągol, Nicolò Paternoster, Ntale Swamadu, oab24413gmai, ocavue, Oliver Speir, oliverlynch, Ossaid, Patrick Linnane, Peter Philipp, Phaneendra, Pierre G., pierreeurope, Quetzal Rivera, R A, Raanelom, Rafael Yasuhide Sudo, Rahul Dogra, Rayan Salhab, Rodrigo Santos, Rohan Santhosh Kumar, Roman, Roman Kholiavko, Sam Richard, sanchezmaldonadojesusadrian14-coder, Sanjaiyan Parthipan, sanjibani, Schahin, Sebastian Beltran, Sebastien Barre, Shinya Fujino, Stefan Machhammer, Stel Clementine, Tay, Tee Ming, thelazylama, Timo Behrmann, tmimmanuel, Tobias Breit, Tom Callahan, Tomasz Cz-Sokołow, travisBREAKS, Tristan Bessoussa, Umut Keltek, Utpal Sen, Vagno, Varun Chawla, Victor Berchet, Vladyslav Shevchenko, Yagiz Nizipli, yy, and 翠

Esperamos que disfrutes Astro 7. Si encuentras problemas o quieres compartir feedback, únete a nosotros en Discord, publica en GitHub, o contáctanos en Bluesky, Twitter, y Mastodon.