[email protected]

Patch Changes

• #14765 03fb47c Thanks @florian-lefebvre! - Fixes a case where process.env wouldn't be properly populated during the build

• #14690 ae7197d Thanks @fredriknorlin! - Fixes a bug where Astro's i18n fallback system with fallbackType: 'rewrite' would not generate fallback files for pages whose filename started with a locale key.

[email protected]

Patch Changes

• #14751 18c55e1 Thanks @delucis! - Fixes hydration of client components when running the dev server and using a barrel file that re-exports both Astro and UI framework components.

• #14750 35122c2 Thanks @florian-lefebvre! - Updates the experimental Fonts API to log a warning if families with a conflicting cssVariable are provided

• #14737 74c8852 Thanks @Arecsu! - Fixes an error when using transition:persist with components that use declarative Shadow DOM. Astro now avoids re-attaching a shadow root if one already exists, preventing "Unable to re-attach to existing ShadowDOM" navigation errors.

• #14750 35122c2 Thanks @florian-lefebvre! - Updates the experimental Fonts API to allow for more granular configuration of remote font families

  A font family is defined by a combination of properties such as weights and styles (e.g. weights: [500, 600] and styles: ["normal", "bold"]), but you may want to download only certain combinations of these.

  For greater control over which font files are downloaded, you can specify the same font (ie. with the same cssVariable, name, and provider properties) multiple times with different combinations. Astro will merge the results and download only the required files. For example, it is possible to download normal 500 and 600 while downloading only italic 500:

  // astro.config.mjs
  import { defineConfig, fontProviders } from 'astro/config';
  
  export default defineConfig({
    experimental: {
      fonts: [
        {
          name: 'Roboto',
          cssVariable: '--roboto',
          provider: fontProviders.google(),
          weights: [500, 600],
          styles: ['normal'],
        },
        {
          name: 'Roboto',
          cssVariable: '--roboto',
          provider: fontProviders.google(),
          weights: [500],
          styles: ['italic'],
        },
      ],
    },
  });

[email protected]

Patch Changes

• #14712 91780cf Thanks @florian-lefebvre! - Fixes a case where build's process.env would be inlined in the server output

• #14713 666d5a7 Thanks @florian-lefebvre! - Improves fallbacks generation when using the experimental Fonts API

• #14743 dafbb1b Thanks @matthewp! - Improves X-Forwarded header validation to prevent cache poisoning and header injection attacks. Now properly validates X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-Port headers against configured allowedDomains patterns, rejecting malformed or suspicious values. This is especially important when running behind a reverse proxy or load balancer.

[email protected]

Major Changes

• #14427 e131261 Thanks @florian-lefebvre! - Increases minimum Node.js version to 22.12.0 - (v6 upgrade guidance)

[email protected]

Patch Changes

• #14703 970ac0f Thanks @ArmandPhilippot! - Adds missing documentation for some public utilities exported from astro:i18n.

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.

• #14711 a4d284d Thanks @deining! - Fixes typos in documenting our error messages and public APIs.

• #14701 9be54c7 Thanks @florian-lefebvre! - Fixes a case where the experimental Fonts API would filter available font files too aggressively, which could prevent the download of woff files when using the google provider

@astrojs/[email protected]

Patch Changes

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.

@astrojs/[email protected]

Patch Changes

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.

@astrojs/[email protected]

Patch Changes

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.

@astrojs/[email protected]

Patch Changes

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.

@astrojs/[email protected]

Patch Changes

• #14715 3d55c5d Thanks @ascorbic! - Adds support for client hydration in getContainerRenderer()

  The getContainerRenderer() function is exported by Astro framework integrations to simplify the process of rendering framework components when using the experimental Container API inside a Vite or Vitest environment. This update adds the client hydration entrypoint to the returned object, enabling client-side interactivity for components rendered using this function. Previously this required users to manually call container.addClientRenderer() with the appropriate client renderer entrypoint.

  See the container-with-vitest demo for a usage example, and the Container API documentation for more information on using framework components with the experimental Container API.