Astro 6.3 — co nowego w najnowszej wersji frameworka?

Na początku maja 2026 zespół Astro wydał wersję 6.3 frameworka. Aktualizacja nie jest tak głośna jak duże wydania majorowe, ale przynosi kilka konkretnych zmian, które warto znać — szczególnie jeśli rozważasz Astro przy nowym projekcie albo masz już stronę opartą o tę technologię.

Najważniejsza nowość to eksperymentalny zaawansowany routing, który daje pełną kontrolę nad tym, jak strona obsługuje przychodzące żądania. Oprócz tego Astro lepiej radzi sobie z obrazami pobieranymi z zewnętrznych źródeł, a domyślne ustawienia dla plików SVG zyskały dodatkowe zabezpieczenia. Po kolei.

Co dokładnie zmienia się w Astro 6.3?

Wydanie 6.3 to nie jest rewolucja, tylko porządne dopinanie szczegółów. Główne kierunki to: większa elastyczność dla zaawansowanych integracji, bezpieczniejsza praca z mediami i drobne ulepszenia w obsłudze ciasteczek. Każda z tych zmian odpowiada na realne potrzeby, które przewijały się w społeczności i na GitHubie przez ostatnie miesiące.

Pełne release notes opublikował Matthew Phillips na oficjalnym blogu Astro 7 maja 2026 roku. Poniżej przekład najważniejszych punktów na polski, z komentarzem od strony praktycznej.

Eksperymentalny zaawansowany routing

To zdecydowanie największa zmiana w 6.3. Astro daje teraz programistom pełną kontrolę nad tym, jak żądania użytkownika przepływają przez stronę. Można podpiąć własne handlery, zdecydować w jakiej kolejności mają się wykonywać, przekierować część ruchu do zewnętrznych serwisów albo wmiksować framework typu Hono prosto w pipeline Astro.

W praktyce oznacza to, że Astro przestaje być „zamkniętą skrzynką” obsługującą tylko swoje strony i staje się elastycznym narzędziem do budowy aplikacji webowych z mieszanym ruchem. Można na przykład serwować wszystko spod / jako klasyczne strony Astro, a /api przekazać do zupełnie innego backendu.

Najprostszy przykład wygląda tak:

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

export default {
  fetch(request: Request) {
    const state = new FetchState(request);
    if (state.url.pathname.startsWith('/api')) {
      return fetch(new URL(state.url.pathname, 'https://api.example.com'));
    }
    return astro(state);
  }
};

W tym kodzie wszystko, co trafia pod adres zaczynający się od /api, leci do zewnętrznego serwisu, a reszta obsługiwana jest standardowo przez Astro.

Jeszcze ciekawiej robi się przy integracji z Hono — lekkim frameworkiem do budowy aplikacji uruchamianych w środowiskach typu Cloudflare Workers, Deno czy Bun. Astro 6.3 udostępnia gotowe handlery zgodne z Hono, dzięki czemu można je dowiązać jako kolejne warstwy middleware:

import { Hono } from 'hono';
import { logger } from 'hono/logger';
import { actions, middleware, pages, i18n } from 'astro/hono';

const app = new Hono();

app.use(logger());
app.use(async (c, next) => {
  if (new URL(c.req.url).pathname.startsWith('/admin')) {
    return c.redirect('/login');
  }
  return next();
});

app.use(actions());
app.use(middleware());
app.use(pages());
app.use(i18n());

export default app;

Programista decyduje, w jakiej kolejności wykonują się: logger, własne middleware, akcje, strony i internacjonalizacja. Astro staje się jednym z bloków układanki, a nie monolitem.

Dostępne handlery, które można złożyć w pipeline, to: astro, trailingSlash, redirects, sessions, actions, middleware, pages, cache oraz i18n. Mogą być importowane z astro/fetch albo astro/hono, w zależności od preferowanego stylu.

Funkcja jest na razie oznaczona jako eksperymentalna — wymaga włączenia odpowiedniej flagi w konfiguracji i może jeszcze ewoluować. Pełna dokumentacja znajduje się w oficjalnych dokumentach Astro.

Obsługa przekierowań w zdalnych obrazach

To zmiana, która brzmi technicznie, ale w praktyce rozwiązuje irytujący problem. Wiele serwisów do hostowania obrazów — CDN-y, biblioteki mediów, integracje z chmurami — nie zwraca pliku bezpośrednio, tylko przekierowuje pod inny adres. Wcześniej Astro w takim przypadku po prostu się gubiło.

W wersji 6.3 framework podąża za maksymalnie 10 przekierowaniami podczas pobierania zdalnego obrazu. Co ważne, każdy adres w łańcuchu przekierowań jest sprawdzany pod kątem konfiguracji bezpieczeństwa (image.remotePatterns lub image.domains). Jeśli któreś z przekierowań prowadzi do hosta, który nie jest dozwolony, dostajesz wyraźny komunikat błędu zamiast cichej porażki.

Praktyczny scenariusz:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    domains: ["example.com", "cdn.example.com"]
  }
});

I użycie w komponencie:

<Image
  src="https://example.com/assets/image.png"
  width="1920"
  height="1080"
  alt="Przykładowy obraz."
/>

Jeśli example.com przekieruje na cdn.example.com — działa, bo oba hosty są na liście. Jeśli jednak przekieruje na malicious.com (nie ma jej na liście) — Astro pokaże błąd, zamiast po cichu pobrać niezweryfikowaną zawartość.

Dla mniej restrykcyjnych projektów można też zezwolić na wszystkie hosty https:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    remotePatterns: [{ protocol: 'https' }]
  }
});

Drobiazg, ale ratuje sporo godzin debugowania przy integracji z zewnętrznymi CDN-ami.

SVG: przetwarzanie domyślnie wyłączone

Tu zespół Astro postawił na bezpieczeństwo. Wcześniej framework potrafił przetwarzać pliki SVG przez Sharp (np. konwertować je do PNG). Problem polega na tym, że SVG to dokument tekstowy, który może zawierać osadzone skrypty. Przetworzenie nieznanego, niezaufanego SVG-a stwarzało potencjalne ryzyko.

W Astro 6.3 ta operacja jest domyślnie wyłączona. Jeśli spróbujesz przekazać SVG do potoku optymalizacji obrazów, dostaniesz wyraźny błąd. Co ważne — import SVG jako komponentu w stronie nadal działa normalnie. Zmiana dotyczy wyłącznie rastryzacji (zamiany na bitmapę typu PNG).

Jeśli faktycznie potrzebujesz tej funkcji i wiesz, że źródła SVG są zaufane, możesz ją włączyć ręcznie:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    dangerouslyProcessSVG: true,
  }
});

Nazwa flagi (dangerouslyProcessSVG) sama w sobie jest sygnałem: użyj świadomie, na własne ryzyko.

Drobne ulepszenia: nowa metoda consume() dla ciasteczek

To zmiana, która ucieszy programistów pracujących z AstroCookies. Pojawiła się nowa metoda consume(), która oznacza ciasteczko jako „skonsumowane” i zwraca odpowiednie nagłówki Set-Cookie. Jeśli po wywołaniu consume() spróbujesz jeszcze raz wywołać set() na tym samym cookie, dostaniesz ostrzeżenie w konsoli.

Funkcja zastępuje wcześniejszą statyczną metodę AstroCookies.consume(cookies), która została oznaczona jako deprecated. Stare wywołanie nadal działa (kompatybilność wsteczna), ale nowy zapis jest czytelniejszy i mniej podatny na błędy.

Co to znaczy w praktyce dla stron firmowych?

Jeśli nie jesteś programistą i czytasz to pod kątem „czy nasza strona w Astro coś z tego skorzysta” — odpowiedź jest prosta: prawdopodobnie tak, ale niewiele zauważysz na pierwszy rzut oka.

Najważniejsze zmiany dotyczą bezpieczeństwa (SVG, walidacja przekierowań) i elastyczności dla bardziej zaawansowanych integracji (routing z Hono). Typowa strona firmowa, landing page albo blog dostają je „w pakiecie” — bez konieczności przerabiania kodu. Aktualizacja do nowszej wersji to dla nas zwykle kilkanaście minut pracy plus weryfikacja, że build i deploy nadal działają poprawnie.

W praktyce częściej będziesz widzieć korzyści wynikające z całej linii Astro 6.x — szybsze buildy, lepsze Core Web Vitals, czystsze typy w content collections. Wersja 6.3 to po prostu kolejny krok w tym samym kierunku.

Jak zaktualizować projekt do Astro 6.3?

Najszybszy sposób:

npx @astrojs/upgrade

Można też ręcznie, w zależności od używanego menedżera paczek:

npm install astro@latest
pnpm upgrade astro --latest
yarn upgrade astro --latest

Po aktualizacji warto uruchomić build (npm run build) i sprawdzić, czy nic nie pęka. Większość projektów przejdzie aktualizację bez modyfikacji. Pełna lista zmian dostępna jest w oficjalnym changelogu Astro na GitHubie.

Jeśli zaczynasz dopiero przygodę z tym frameworkiem, polecamy nasz wstępniak: Co to jest Astro? Nowoczesny framework do budowy szybkich stron. A jeśli zastanawiasz się, czy warto migrować z WordPressa na Astro, mamy też osobny tekst: Dlaczego Astro zamiast WordPressa?.

W Astrofy na bieżąco aktualizujemy projekty naszych klientów do najnowszych stabilnych wersji Astro. Jeśli masz stronę, którą warto przebudować, lub planujesz nowy projekt — napisz do nas, chętnie sprawdzimy, co da się zrobić.