[email protected]

Major Changes

• #14956 0ff51df Thanks @matthewp! - Astro v6.0 upgrades to Zod v4 for schema validation - (v6 upgrade guidance)

• #14759 d7889f7 Thanks @florian-lefebvre! - Updates how schema types are inferred for content loaders with schemas (Loader API) - (v6 upgrade guidance)

• #14306 141c4a2 Thanks @ematipico! - Removes support for routes with percent-encoded percent signs (e.g. %25) - (v6 upgrade guidance)

• #14759 d7889f7 Thanks @florian-lefebvre! - Removes the option to define dynamic schemas in content loaders as functions and adds a new equivalent createSchema() property (Loader API) - (v6 upgrade guidance)

• #14306 141c4a2 Thanks @ematipico! - Removes RouteData.generate from the Integration API - (v6 upgrade guidance)

• #14989 73e8232 Thanks @florian-lefebvre! - Deprecates exposed astro:transitions internals - (v6 upgrade guidance)

• #14758 010f773 Thanks @florian-lefebvre! - Removes the setManifestData method from App and NodeApp (Adapter API) - (v6 upgrade guidance)

• #14826 170f64e Thanks @florian-lefebvre! - Removes the experimental.failOnPrerenderConflict flag and replaces it with a new configuration option prerenderConflictBehavior - (v6 upgrade guidance)

• #14923 95a1969 Thanks @florian-lefebvre! - Deprecates astro:schema and z from astro:content in favor of astro/zod - (v6 upgrade guidance)

• #14844 8d43b1d Thanks @trueberryless! - Removes exposed astro:actions internals - (v6 upgrade guidance)

• #14306 141c4a2 Thanks @ematipico! - Changes the shape of SSRManifest properties and adds several new required properties in the Adapter API - (v6 upgrade guidance)

• #14306 141c4a2 Thanks @ematipico! - Changes integration hooks and HMR access patterns in the Integration API - (v6 upgrade guidance)

• #14306 141c4a2 Thanks @ematipico! - Removes the unused astro:ssr-manifest virtual module - (v6 upgrade guidance)

Minor Changes

• #14306 141c4a2 Thanks @ematipico! - Adds new optional properties to setAdapter() for adapter entrypoint handling in the Adapter API

  Changes:

  • New optional properties:
    • devEntrypoint?: string | URL - specifies custom dev server entrypoint
    • entryType?: 'self' | 'legacy-dynamic' - determines if the adapter provides its own entrypoint ('self') or if Astro constructs one ('legacy-dynamic', default)

  Migration: Adapter authors can optionally add these properties to support custom dev entrypoints. If not specified, adapters will use the legacy behavior.

• #14826 170f64e Thanks @florian-lefebvre! - Adds an option prerenderConflictBehavior to configure the behavior of conflicting prerendered routes

  By default, Astro warns you during the build about any conflicts between multiple dynamic routes that can result in the same output path. For example /blog/[slug] and /blog/[...all] both could try to prerender the /blog/post-1 path. In such cases, Astro renders only the highest priority route for the conflicting path. This allows your site to build successfully, although you may discover that some pages are rendered by unexpected routes.

  With the new prerenderConflictBehavior configuration option, you can now configure this further:

  • prerenderConflictBehavior: 'error' fails the build
  • prerenderConflictBehavior: 'warn' (default) logs a warning and the highest-priority route wins
  • prerenderConflictBehavior: 'ignore' silently picks the highest-priority route when conflicts occur

  import { defineConfig } from 'astro/config';
  
  export default defineConfig({
  +    prerenderConflictBehavior: 'error',
  });

• #14946 95c40f7 Thanks @ematipico! - Removes the experimental.csp flag and replaces it with a new configuration option security.csp - (v6 upgrade guidance)

Patch Changes

• #14982 6849e38 Thanks @Princesseuh! - Fixes images outside the project directory not working when using astro:assets in development mode

@astrojs/[email protected]

Minor Changes

• #14946 95c40f7 Thanks @ematipico! - Removes the experimental.csp flag and replaces it with a new configuration option security.csp - (v6 upgrade guidance)

@astrojs/[email protected]

Patch Changes

• #14956 0ff51df Thanks @matthewp! - Updates usage of zod to own dependency rather than relying on astro/zod

@astrojs/[email protected]

Patch Changes

• #14956 0ff51df Thanks @matthewp! - Updates usage of zod to own dependency rather than relying on astro/zod

@astrojs/[email protected]

Minor Changes

• #14946 95c40f7 Thanks @ematipico! - Removes the experimental.csp flag and replaces it with a new configuration option security.csp - (v6 upgrade guidance)

@astrojs/[email protected]

Minor Changes

• #14946 95c40f7 Thanks @ematipico! - Removes the experimental.csp flag and replaces it with a new configuration option security.csp - (v6 upgrade guidance)

Patch Changes

• Updated dependencies []:
  • @astrojs/[email protected]

@astrojs/[email protected]

Patch Changes

• #14956 0ff51df Thanks @matthewp! - Updates usage of zod to own dependency rather than relying on astro/zod

@astrojs/[email protected]

Major Changes

• #14306 141c4a2 Thanks @ematipico! - Changes the API for creating a custom entrypoint, replacing the createExports() function with a direct export pattern.

  What should I do?

  If you're using a custom entryPoint in your Cloudflare adapter config, update your existing worker file that uses createExports() to reflect the new, simplified pattern:

  my-entry.ts

  import type { SSRManifest } from 'astro';
  import { App } from 'astro/app';
  import { handle } from '@astrojs/cloudflare/handler';
  import { DurableObject } from 'cloudflare:workers';
  
  class MyDurableObject extends DurableObject<Env> {
    constructor(ctx: DurableObjectState, env: Env) {
      super(ctx, env);
    }
  }
  
  export function createExports(manifest: SSRManifest) {
    const app = new App(manifest);
    return {
      default: {
        async fetch(request, env, ctx) {
          await env.MY_QUEUE.send('log');
          return handle(manifest, app, request, env, ctx);
        },
        async queue(batch, _env) {
          let messages = JSON.stringify(batch.messages);
          console.log(`consumed from our queue: ${messages}`);
        },
      } satisfies ExportedHandler<Env>,
      MyDurableObject: MyDurableObject,
    };
  }

  To create the same custom entrypoint using the updated API, export the following function instead:

  my-entry.ts

  import { handle } from '@astrojs/cloudflare/utils/handler';
  
  export default {
    async fetch(request, env, ctx) {
      await env.MY_QUEUE.send("log");
      return handle(manifest, app, request, env, ctx);
    },
    async queue(batch, _env) {
      let messages = JSON.stringify(batch.messages);
      console.log(`consumed from our queue: ${messages}`);
    }
  } satisfies ExportedHandler<Env>,

  The manifest is now created internally by the adapter.

• #14306 141c4a2 Thanks @ematipico! - Development server now runs in workerd

  astro dev now runs your Cloudflare application using Cloudflare's workerd runtime instead of Node.js. This means your development environment is now a near-exact replica of your production environment—the same JavaScript engine, the same APIs, the same behavior. You'll catch issues during development that would have only appeared in production, and features like Durable Objects, Workers Analytics Engine, and R2 bindings work exactly as they do on Cloudflare's platform.

  To accommodate this major change to your development environment, this update includes breaking changes to Astro.locals.runtime, removing some of its properties.

  What should I do?

  Update occurrences of Astro.locals.runtime as shown below:

  • Astro.locals.runtime no longer contains the env object. Instead, import it directly:

    import { env } from 'cloudflare:workers';

  • Astro.locals.runtime no longer contains the cf object. Instead, access it directly from the request:

    Astro.request.cf;

  • Astro.locals.runtime no longer contains the caches object. Instead, use the global caches object directly:

    caches.default.put(request, response);

  • Astro.locals.runtime object is replaced with Astro.locals.cfContext which contains the Cloudflare ExecutionContext:

    const cfContext = Astro.locals.cfContext;

Minor Changes

• #14306 141c4a2 Thanks @ematipico! - Adds support for astro preview command

  Developers can now use astro preview to test their Cloudflare Workers application locally before deploying. The preview runs using Cloudflare's workerd runtime, giving you a staging environment that matches production exactly—including support for KV namespaces, environment variables, and other Cloudflare-specific features.

Patch Changes

• Updated dependencies []:
  • @astrojs/[email protected]

[email protected]

Patch Changes

• #14985 c016f10 Thanks @florian-lefebvre! - Fixes a case where JSDoc annotations wouldn't show for fonts related APIs in the Astro config

• #14973 ed7cc2f Thanks @amankumarpandeyin! - Fixes performance regression and OOM errors when building medium-sized blogs with many content entries. Replaced O(n²) object spread pattern with direct mutation in generateLookupMap.

• #14958 70eb542 Thanks @ascorbic! - Gives a helpful error message if a user sets output: "hybrid" in their Astro config.

  The option was removed in Astro 5, but lots of content online still references it, and LLMs often suggest it. It's not always clear that the replacement is output: "static", rather than output: "server". This change adds a helpful error message to guide humans and robots.

• #14901 ef53716 Thanks @Darknab! - Updates the glob() loader to log a warning when duplicated IDs are detected

• Updated dependencies [d8305f8]:

  • @astrojs/[email protected]

[email protected]

Patch Changes

• #14988 a3a20d8 Thanks @Princesseuh! - Retries failed deploy