AstroEco is Contributing…

Display your GitHub pull requests using astro-loader-github-prs

fix: loosen live collection stack parsing

Changes

A difference in the stack trace format was causing live collecitons to incorrectly complain that the colleciton was defined in the wrong file. Also in some cases such as when there's a space in the filename, the stack doesn't include the filename at all, giving another false error.

This PR loosens the check to make it more forgiving, and to not assume the worst if no filename can be found

Closes #13980

Testing

Tested manually

Docs

fix: add info message in dev

withastro/astro

#13987 Jun 20

Changes

This PR adds a small message that is shown in dev mode when users use CSP.

Testing

Docs

/cc @withastro/maintainers-docs for feedback!

I would appreciate some feedback around the nature of the message. I decided to use info severity. Should we use warning?

fix: toolbar image audit in content collections

withastro/astro

#13983 Jun 20

Changes

Closes #13221
The dev toolbar relies on the data-image-component attribute for an audit
In content collections md/mdx files, images are not created using the <Image /> component so the attribute was not set in dev

Testing

Manually

Docs

Changeset

[ci] release

withastro/astro

#13981 Jun 20

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

astro@5.10.1

Patch Changes

#13909 b258d86 Thanks @isVivek99! - Fixes rendering of special boolean attributes for custom elements
#13983 e718375 Thanks @florian-lefebvre! - Fixes a case where the toolbar audit would incorrectly flag images processed by Astro in content collections documents
#13985 0b4c641 Thanks @jsparkdev! - Updates wrong link

Fix heading hierarchy for recent releases in `astro` and `@astrojs/vercel` changelogs

withastro/astro

#13978 Jun 19

Changes

Updates chanhelogs to avoid using h2/h3 headings inside changelog entries
This ensures headings are sequential and relate to the h2 and h3 headings added by changesets

Testing

n/a

Docs

Yup.

Add missing danish UI translations

withastro/starlight

#3252 Jun 19

Description

Adds missing danish UI translations.

fix: actions typegen path

withastro/astro

#13976 Jun 19

Changes

Closes #13903
Instead of hardcoding what path to use, we grab the matched action filename and use directly

Testing

Manually

Docs

Changeset

feat(node): experimental static headers

withastro/astro

#13972 Jun 18

Changes

This PR implements static headers for the Node.js adapter. To support it, the adapter now creates a _headers.json file during the build, which has the following shape:

[
	{
		"source": "/blog/[...slug]", // it uses `RouteData.route`, which is a unique pattern
		"headers": [
			{
				"key": "Content-Security-Policy",
				"value": "script-src: ... "
			}
		]
	}
]

This file is read by the Node.js adapter when it starts the server, and its value is stored inside NodeApp class.

The inconvenient part is that both NodeApp and App belong to core, so any solution would force a minor into astro. Because of that, I decided to apply a more generic solution, because App has access to the manifest, which contains the list of routes. App.match doesn't return matched RouteData, but with a new, optional parameter, it's possible to return them.

The static handler of the Node.js adapter checks if a RouteData matches the request, and if there's a corresponding header, it's added to the final response!

Testing

Added new tests

Docs

Added two changesets:

one for the adapter
one for the internal changes in Astro (minor, unfortunately)

don't coerce environment variable values when populating import.meta.env

withastro/astro

#13971 Jun 18

Changes

Closes #13967

Just to go over my thought process:

The env-loader logic is used for both populating the astro:env virtual modules and import.meta.env.
We want variables imported via astro:env to still be converted into the expected type.
We want variables on import.meta.env to not be converted and should be set as-is (i.e. a string).
astro:env is entirely set up in vite-plugin-env.ts (?)
import.meta.env is entirely set up in vite-plugin-import-meta-env.ts (?)

I added a coerceValues argument to createEnvLoader and getPrivateEnv.

Then, in packages/astro/src/core/create-vite.ts, we create two separate envLoaders, one more astro:env and one for import.meta.env, where the the importMetaEnv plugin is passed an envLoader with coerceValues = false.

Alternate Solution

The above solution requires making two envLoaders.

As an alternative, we could attach a property to the object returned by createEnvLoader called something like getRawPrivateEnv which contains the original string values. We would use one envLoader and then in vite-plugin-import-meta-env.ts we usegetRawPrivateEnv instead of getPrivateEnv.

Testing

I tested with the examples/minimal project:

Add the following to index.astro:

 import { MY_VAR } from 'astro:env/client';
 console.log(`typeof: ${typeof import.meta.env.MY_VAR}`);
 console.log(`typeof: ${typeof MY_VAR}`);

Set up the astro.config:

 export default defineConfig({env: {
 	schema: {
 		MY_VAR: {
 			access: "public",
 			context: "client",
 			type: "boolean",
 			
 		}
 	}
 }});

Run MY_VAR=true pnpm --filter @example/minimal run build:

 typeof: string // from import.meta.env
 typeof: boolean // from astro:env

Docs

I don't think this needs doc changes.

fix(astro): Fix SVG file-level duplication in build output

withastro/astro

#13968 Jun 18

Changes

Fix SVG file-level duplication: Prevent identical SVG content from being physically stored multiple times on disk
Add content-based deduplication: Implement SHA256 content hashing to detect duplicate SVG files regardless of import path or filename
Use hard link optimization: Create hard links for duplicate content instead of separate physical files
Preserve existing behavior: Maintain all expected filenames and HTML references while optimizing storage

Before

Source files:     duplicate1.svg, duplicate2.svg (identical), unique.svg
Generated files:  4 separate physical SVG files in _astro/ directory
Storage impact:   100% overhead for duplicate content

After

Source files:     duplicate1.svg, duplicate2.svg (identical), unique.svg  
Generated files:  4 filenames → 2 physical files (hard linked)
Storage impact:   Optimal - duplicate content stored only once

Testing

Added comprehensive test suite (file-level-svg-deduplication.test.js) with 4 test cases:
- Hard link verification: Validates that duplicate content uses hard links instead of separate files
- Physical file count: Ensures only unique content creates physical files (2 inodes for 2 unique contents)
- Filename preservation: Confirms all expected filenames exist and HTML references work correctly
- Content validation: Verifies duplicate detection using SHA256 content hashing
Test results demonstrate optimization:
- 4 filenames available → 2 physical files (inodes) → 2 hard link pairs
- Storage reduction: ~50% for projects with duplicate SVG content
- Zero breaking changes: All expected filenames and references preserved

Docs

No documentation changes needed - this is an internal build optimization that doesn't affect user-facing APIs or behavior.

Preserves all existing filenames: Each import still gets its expected filename reference
Maintains HTML output: Generated HTML references remain unchanged from user perspective
No breaking changes: Pure storage optimization with no API or behavior changes
Automatic performance improvement: Users benefit from reduced disk usage without code changes

Related Issues: Closes #13910

Fix broken documentation link

withastro/astro

#13966 Jun 18

Changes

Previously, it led to https://docs.astro.build/en/reference/configuration-reference/#trailingslash%22 (see the double quote at the end of the URL)

Docs

The 404 page template was fixed, there is no reason to touch the documentation.

feat(vercel): experimental static headers

withastro/astro

#13965 Jun 18

Changes

Very similar to #13952, it adds support for static headers in the Vercel adapter

Testing

Added a new test

Docs

The changeset is a copy-past from the netlify one, updated to use the vercel adapter.

/cc @withastro/maintainers-docs for feedback!

fix(cloudflare): dispose platform proxy on server close

withastro/astro

#13963 Jun 18

Changes

Closes #13947

Testing

Manually

Docs

Changeset

feat(cloudflare): add experimental support for static headers

withastro/astro

#13959 Jun 17

Changes

This is my first ever change to astro. So I am not sure this is the correct way. Therefore a more thorough review may be required.

The PR aims to implement the experimental CSP policy to the cloudflare adapter.

Mainly copied work from: de82ef2

Testing

Added tests. Existing tests should still pass.

Validate CF docs if output matches.

Example output:

/has-header
  cdn-cache-control: public, max-age=3600
  Content-Security-Policy: script-src 'self' 'sha256-BF0290pkb3jxQsE7z00xR8Imp8X34FLC88L0lkMnrGw=' 'sha256-QzWFZi+FLIx23tnm9SBU4aEgx4x8DsuASP07mfqol/c=' 'sha256-0chmwFk0zaA528yFfGV7J9ppIpdfTPPULncDF3WG7Zs=' 'sha256-eIXWvAmxkr251LJZkjniEK5LcPF3NkapbJepohwYRIc=' 'sha256-Q2BPg90ZMplYY+FSdApNErhpWafg2hcRRbndmvxuL/Q=' 'sha256-0oe0j1+KVmVYcHm1N1/3tGTf3Yhpnd6heIyJsO4LZS0=' 'sha256-Yfb49Tdgb3WWkhZG+Levy7SSbIwvHj9bEqvunWdMcuU='; style-src 'self' 'sha256-2sYicASgHviyvFSsZfd8xuNIhA0b8XasqB2neZePwjs=';

/parent/*/page
  Content-Security-Policy: script-src 'self' 'sha256-BF0290pkb3jxQsE7z00xR8Imp8X34FLC88L0lkMnrGw=' 'sha256-QzWFZi+FLIx23tnm9SBU4aEgx4x8DsuASP07mfqol/c=' 'sha256-0chmwFk0zaA528yFfGV7J9ppIpdfTPPULncDF3WG7Zs=' 'sha256-eIXWvAmxkr251LJZkjniEK5LcPF3NkapbJepohwYRIc=' 'sha256-Q2BPg90ZMplYY+FSdApNErhpWafg2hcRRbndmvxuL/Q=' 'sha256-0oe0j1+KVmVYcHm1N1/3tGTf3Yhpnd6heIyJsO4LZS0=' 'sha256-ByjyHeCbp9JwIvEz5gjdoP7siW4JyclCitgVszsv3/A='; style-src 'self' 'sha256-2sYicASgHviyvFSsZfd8xuNIhA0b8XasqB2neZePwjs=';

/
  Content-Security-Policy: script-src 'self' 'sha256-BF0290pkb3jxQsE7z00xR8Imp8X34FLC88L0lkMnrGw=' 'sha256-QzWFZi+FLIx23tnm9SBU4aEgx4x8DsuASP07mfqol/c=' 'sha256-0chmwFk0zaA528yFfGV7J9ppIpdfTPPULncDF3WG7Zs=' 'sha256-eIXWvAmxkr251LJZkjniEK5LcPF3NkapbJepohwYRIc=' 'sha256-Q2BPg90ZMplYY+FSdApNErhpWafg2hcRRbndmvxuL/Q=' 'sha256-0oe0j1+KVmVYcHm1N1/3tGTf3Yhpnd6heIyJsO4LZS0=' 'sha256-v10nX5cSfrpnBaKOp54plCw0M1DSmiPyeQyg//eGOnA='; style-src 'self' 'sha256-2sYicASgHviyvFSsZfd8xuNIhA0b8XasqB2neZePwjs=';

/*
  Content-Security-Policy: script-src 'self' 'sha256-BF0290pkb3jxQsE7z00xR8Imp8X34FLC88L0lkMnrGw=' 'sha256-QzWFZi+FLIx23tnm9SBU4aEgx4x8DsuASP07mfqol/c=' 'sha256-0chmwFk0zaA528yFfGV7J9ppIpdfTPPULncDF3WG7Zs=' 'sha256-eIXWvAmxkr251LJZkjniEK5LcPF3NkapbJepohwYRIc=' 'sha256-Q2BPg90ZMplYY+FSdApNErhpWafg2hcRRbndmvxuL/Q=' 'sha256-0oe0j1+KVmVYcHm1N1/3tGTf3Yhpnd6heIyJsO4LZS0=' 'sha256-84Lsggi8q1VFTLi2blghehwqNiFOYysZSnNhkaidDMk='; style-src 'self' 'sha256-2sYicASgHviyvFSsZfd8xuNIhA0b8XasqB2neZePwjs=';

Docs

Docs needs to be added, todo based on feedback.

[ci] release

withastro/astro

#13958 Jun 17

Releases

astro@5.10.0

Minor Changes

#13917 e615216 Thanks @ascorbic! - Adds a new priority attribute for Astro's image components.

This change introduces a new priority option for the <Image /> and <Picture /> components, which automatically sets the loading, decoding, and fetchpriority attributes to their optimal values for above-the-fold images which should be loaded immediately.

It is a boolean prop, and you can use the shorthand syntax by simply adding priority as a prop to the <Image /> or <Picture /> component. When set, it will apply the following attributes:
- loading="eager"
- decoding="sync"
- fetchpriority="high"
The individual attributes can still be set manually if you need to customize your images further.

By default, the Astro <Image /> component generates <img> tags that lazy-load their content by setting loading="lazy" and decoding="async". This improves performance by deferring the loading of images that are not immediately visible in the viewport, and gives the best scores in performance audits like Lighthouse.

The new priority attribute will override those defaults and automatically add the best settings for your high-priority assets.

This option was previously available for experimental responsive images, but now it is a standard feature for all images.

Usage
```
<Image src="/path/to/image.jpg" alt="An example image" priority />
```
[!Note]
You should only use the priority option for images that are critical to the initial rendering of the page, and ideally only one image per page. This is often an image identified as the LCP element when running Lighthouse tests. Using it for too many images will lead to performance issues, as it forces the browser to load those images immediately, potentially blocking the rendering of other content.
#13917 e615216 Thanks @ascorbic! - The responsive images feature introduced behind a flag in v5.0.0 is no longer experimental and is available for general use.

The new responsive images feature in Astro automatically generates optimized images for different screen sizes and resolutions, and applies the correct attributes to ensure that images are displayed correctly on all devices.

Enable the image.responsiveStyles option in your Astro config. Then, set a layout attribute on any or component, or configure a default image.layout, for instantly responsive images with automatically generated srcset and sizes attributes based on the image's dimensions and the layout type.

Displaying images correctly on the web can be challenging, and is one of the most common performance issues seen in sites. This new feature simplifies the most challenging part of the process: serving your site visitor an image optimized for their viewing experience, and for your website's performance.

For full details, see the updated Image guide.

Migration from Experimental Responsive Images

The experimental.responsiveImages flag has been removed, and all experimental image configuration options have been renamed to their final names.

If you were using the experimental responsive images feature, you'll need to update your configuration:

Remove the experimental flag
```
export default defineConfig({
   experimental: {
-    responsiveImages: true,
   },
});
```
Update image configuration options

During the experimental phase, default styles were applied automatically to responsive images. Now, you need to explicitly set the responsiveStyles option to true if you want these styles applied.
```
export default defineConfig({
  image: {
+    responsiveStyles: true,
  },
});
```
The experimental image configuration options have been renamed:

Before:
```
export default defineConfig({
  image: {
    experimentalLayout: 'constrained',
    experimentalObjectFit: 'cover',
    experimentalObjectPosition: 'center',
    experimentalBreakpoints: [640, 750, 828, 1080, 1280],
    experimentalDefaultStyles: true,
  },
  experimental: {
    responsiveImages: true,
  },
});
```
After:
```
export default defineConfig({
  image: {
    layout: 'constrained',
    objectFit: 'cover',
    objectPosition: 'center',
    breakpoints: [640, 750, 828, 1080, 1280],
    responsiveStyles: true, // This is now *false* by default
  },
});
```
Component usage remains the same

The layout, fit, and position props on <Image> and <Picture> components work exactly the same as before:
```
<Image
  src={myImage}
  alt="A responsive image"
  layout="constrained"
  fit="cover"
  position="center"
/>
```
If you weren't using the experimental responsive images feature, no changes are required.

Please see the Image guide for more information on using responsive images in Astro.
#13685 3c04c1f Thanks @ascorbic! - Adds experimental support for live content collections

Live content collections are a new type of content collection that fetch their data at runtime rather than build time. This allows you to access frequently-updated data from CMSs, APIs, databases, or other sources using a unified API, without needing to rebuild your site when the data changes.

Live collections vs build-time collections

In Astro 5.0, the content layer API added support for adding diverse content sources to content collections. You can create loaders that fetch data from any source at build time, and then access it inside a page via getEntry() and getCollection(). The data is cached between builds, giving fast access and updates.

However there is no method for updating the data store between builds, meaning any updates to the data need a full site deploy, even if the pages are rendered on-demand. This means that content collections are not suitable for pages that update frequently. Instead, today these pages tend to access the APIs directly in the frontmatter. This works, but leads to a lot of boilerplate, and means users don't benefit from the simple, unified API that content loaders offer. In most cases users tend to individually create loader libraries that they share between pages.

Live content collections solve this problem by allowing you to create loaders that fetch data at runtime, rather than build time. This means that the data is always up-to-date, without needing to rebuild the site.

How to use

To enable live collections add the experimental.liveContentCollections flag to your astro.config.mjs file:
```
{
  experimental: {
    liveContentCollections: true,
  },
}
```
Then create a new src/live.config.ts file (alongside your src/content.config.ts if you have one) to define your live collections with a live loader and optionally a schema using the new defineLiveCollection() function from the astro:content module.
```
import { defineLiveCollection } from 'astro:content';
import { storeLoader } from '@mystore/astro-loader';

const products = defineLiveCollection({
  type: 'live',
  loader: storeLoader({
    apiKey: process.env.STORE_API_KEY,
    endpoint: 'https://api.mystore.com/v1',
  }),
});

export const collections = { products };
```
You can then use the dedicated getLiveCollection() and getLiveEntry() functions to access your live data:
```
---
import { getLiveCollection, getLiveEntry, render } from 'astro:content';

// Get all products
const { entries: allProducts, error } = await getLiveCollection('products');
if (error) {
  // Handle error appropriately
  console.error(error.message);
}

// Get products with a filter (if supported by your loader)
const { entries: electronics } = await getLiveCollection('products', { category: 'electronics' });

// Get a single product by ID (string syntax)
const { entry: product, error: productError } = await getLiveEntry('products', Astro.params.id);
if (productError) {
  return Astro.redirect('/404');
}

// Get a single product with a custom query (if supported by your loader) using a filter object
const { entry: productBySlug } = await getLiveEntry('products', { slug: Astro.params.slug });

const { Content } = await render(product);
---

<h1>{product.title}</h1>
<Content />
```
See the docs for the experimental live content collections feature for more details on how to use this feature, including how to create a live loader. Please give feedback on the RFC PR if you have any suggestions or issues.

Patch Changes

#13957 304df34 Thanks @ematipico! - Fixes an issue where report-uri wasn't available in experimental.csp.directives, causing a typing error and a runtime validation error.
#13957 304df34 Thanks @ematipico! - Fixes a type error for the CSP directives upgrade-insecure-requests, sandbox, and trusted-type.
#13862 fe8f61a Thanks @florian-lefebvre! - Fixes a case where the dev toolbar would crash if it could not retrieve some essential data
#13976 0a31d99 Thanks @florian-lefebvre! - Fixes a case where Astro Actions types would be broken when using a tsconfig.json with "moduleResolution": "nodenext"

@astrojs/cloudflare@12.6.0

Minor Changes

#13837 7cef86f Thanks @alexanderniebuhr! - Adds new configuration options to allow you to set a custom workerEntryPoint for Cloudflare Workers. This is useful if you want to use features that require handlers (e.g. Durable Objects, Cloudflare Queues, Scheduled Invocations) not supported by the basic generic entry file.

This feature is not supported when running the Astro dev server. However, you can run astro build followed by either wrangler deploy (to deploy it) or wrangler dev to preview it.

The following example configures a custom entry file that registers a Durable Object and a queue handler:

// astro.config.ts
import cloudflare from '@astrojs/cloudflare';
import { defineConfig } from 'astro/config';

export default defineConfig({
  adapter: cloudflare({
    workerEntryPoint: {
      path: 'src/worker.ts',
      namedExports: ['MyDurableObject'],
    },
  }),
});

// src/worker.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,
  };
}

Patch Changes

#13963 c667c55 Thanks @florian-lefebvre! - Fixes a case where the platform proxy would not be disposed when the dev process ended
Updated dependencies []:
- @astrojs/underscore-redirects@1.0.0

@astrojs/vercel@8.2.0

Minor Changes

#13965 95ece06 Thanks @ematipico! - Adds support for the experimental static headers Astro feature.

When the feature is enabled via option experimentalStaticHeaders, and experimental Content Security Policy is enabled, the adapter will generate Response headers for static pages, which allows support for CSP directives that are not supported inside a <meta> tag (e.g. frame-ancestors).
```
import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel';

export default defineConfig({
  adapter: vercel({
    experimentalStaticHeaders: true,
  }),
  experimental: {
    cps: true,
  },
});
```

Patch Changes

#13917 e615216 Thanks @ascorbic! - The responsive images feature introduced behind a flag in v5.0.0 is no longer experimental and is available for general use.

The new responsive images feature in Astro automatically generates optimized images for different screen sizes and resolutions, and applies the correct attributes to ensure that images are displayed correctly on all devices.

Enable the image.responsiveStyles option in your Astro config. Then, set a layout attribute on any or component, or configure a default image.layout, for instantly responsive images with automatically generated srcset and sizes attributes based on the image's dimensions and the layout type.

Displaying images correctly on the web can be challenging, and is one of the most common performance issues seen in sites. This new feature simplifies the most challenging part of the process: serving your site visitor an image optimized for their viewing experience, and for your website's performance.

For full details, see the updated Image guide.

Migration from Experimental Responsive Images

The experimental.responsiveImages flag has been removed, and all experimental image configuration options have been renamed to their final names.

If you were using the experimental responsive images feature, you'll need to update your configuration:

Remove the experimental flag
```
export default defineConfig({
   experimental: {
-    responsiveImages: true,
   },
});
```
Update image configuration options

During the experimental phase, default styles were applied automatically to responsive images. Now, you need to explicitly set the responsiveStyles option to true if you want these styles applied.
```
export default defineConfig({
  image: {
+    responsiveStyles: true,
  },
});
```
The experimental image configuration options have been renamed:

Before:
```
export default defineConfig({
  image: {
    experimentalLayout: 'constrained',
    experimentalObjectFit: 'cover',
    experimentalObjectPosition: 'center',
    experimentalBreakpoints: [640, 750, 828, 1080, 1280],
    experimentalDefaultStyles: true,
  },
  experimental: {
    responsiveImages: true,
  },
});
```
After:
```
export default defineConfig({
  image: {
    layout: 'constrained',
    objectFit: 'cover',
    objectPosition: 'center',
    breakpoints: [640, 750, 828, 1080, 1280],
    responsiveStyles: true, // This is now *false* by default
  },
});
```
Component usage remains the same

The layout, fit, and position props on <Image> and <Picture> components work exactly the same as before:
```
<Image
  src={myImage}
  alt="A responsive image"
  layout="constrained"
  fit="cover"
  position="center"
/>
```
If you weren't using the experimental responsive images feature, no changes are required.

Please see the Image guide for more information on using responsive images in Astro.
Updated dependencies []:
- @astrojs/underscore-redirects@1.0.0

fix(csp): types and validation issues

withastro/astro

#13957 Jun 17

Changes

This PR addresses a couple of issues that were encoureted during the API bash of CSP withastro/roadmap#1168 (comment)

Testing

Added new tests

Docs

Update csp.ts

withastro/astro

#13953 Jun 16

Apparently 'strict-dynamic' needs quotes

Changes

I just added quotes to strict-dynamic, so the experimental CSP feature render it with quotes. Otherwise validators complain (see the image)

Docs on strict-dynamic use quotes too:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src

feat(netlify): add experimental support for static headers

withastro/astro

#13952 Jun 16

Changes

This PR adds support for static headers for the Netlify adapter. The initial implementation supports the experimental CSP feature. In the future, this may change, and we will update the documentation as needed.

`@astrojs/underscore-redirects`

To implement the feature, I had to make some breaking changes within underscore-redirects. The package is mostly for internal usage, so we don't have strong documentation and it's mostly for our needs, so the changesets are mostly technical.

The functionality for redirects must stay the same.

The printing logic has been removed from Redirects, instead consumers need to use printAsRedirects instead. The core functionality hasn't changed much, it now accounts for .target, because it's now optional.

`@astrojs/netlify`

The function that creates config.json is now called in the astro:build:done hook, because we need to collect the static headers from the hook astro:build:generated.

The new logic now loops through the new static headers, and if cps is enabled, they are added to the final config.json.

Testing

Added a new test. Existing tests should still pass.

Docs

fix: make session driver name optional

withastro/astro

#13951 Jun 16

Changes

Currently the session config object is optional, but if provided it must have a driver specified. This caused issues when trying to provide custom configuration to an automatically-provided session driver, such as Cloudflare or Netlify. This PR makes the value optional. It still validates that a driver has been provided once it is first used, so this will catch cases where no driver is provided by either the user or the adapter.

Makes the session driver name optional in config.

Fixes #13920

Testing

Added a test case

Docs

fix(deps): update dependency @nanostores/preact to v1

withastro/astro

#13950 Jun 16

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@nanostores/preact	`^0.5.2` -> `^1.0.0`

Release Notes

nanostores/preact (@nanostores/preact)

Package	Change	Age	Adoption	Passing	Confidence
@types/diff	`^5.2.3` -> `^8.0.0`
@types/picomatch (source)	`^3.0.2` -> `^4.0.0`
@types/react (source)	`^18.3.20` -> `^19.1.8`
@types/react-dom (source)	`^18.3.5` -> `^19.1.6`
diff	`^5.2.0` -> `^8.0.2`
execa	`^8.0.1` -> `^9.6.0`
react (source)	`^18.3.1` -> `^19.1.0`
react-dom (source)	`^18.3.1` -> `^19.1.0`
tinyexec	`^0.3.2` -> `^1.0.1`
yargs-parser	`^21.1.1` -> `^22.0.0`
yocto-spinner	`^0.2.1` -> `^1.0.0`

Package	Change	Age	Adoption	Passing	Confidence
@types/react (source)	`^18.3.23` -> `^19.1.8`
@types/react-dom (source)	`^18.3.7` -> `^19.1.6`
react (source)	`^18.3.1` -> `^19.1.0`
react-dom (source)	`^18.3.1` -> `^19.1.0`

Package	Change	Age	Adoption	Passing	Confidence
@sveltejs/vite-plugin-svelte (source)	`^5.0.3` -> `^5.1.0`
@vitejs/plugin-react (source)	`^4.5.0` -> `^4.5.2`
@vue/compiler-sfc (source)	`^3.5.16` -> `^3.5.17`
cheerio (source)	`1.0.0` -> `1.1.0`
linkedom	`^0.18.10` -> `^0.18.11`
preact (source)	`^10.26.8` -> `^10.26.9`
svelte (source)	`^5.33.14` -> `^5.34.7`
svelte2tsx (source)	`^0.7.39` -> `^0.7.40`
vite-plugin-vue-devtools (source)	`^7.7.6` -> `^7.7.7`
vue (source)	`^3.5.16` -> `^3.5.17`

Package	Change	Age	Adoption	Passing	Confidence
@netlify/blobs	`^8.2.0` -> `^9.1.5`
@netlify/functions	`^3.1.5` -> `^4.1.2`
execa	`^8.0.1` -> `^9.6.0`
express (source)	`^4.21.2` -> `^5.1.0`

Package	Change	Age	Adoption	Passing	Confidence
@preact/signals (source)	`^2.0.5` -> `^2.2.0`
@types/react (source)	`^18.3.22` -> `^18.3.23`
@vitejs/plugin-react (source)	`^4.5.0` -> `^4.5.1`
@vue/compiler-sfc (source)	`^3.5.15` -> `^3.5.16`
preact (source)	`^10.26.7` -> `^10.26.8`
svelte (source)	`^5.33.2` -> `^5.33.14`
vue (source)	`^3.5.15` -> `^3.5.16`

Changes

Testing

Docs

Changes

Testing

Docs

Changes

Testing

Docs

Releases

astro@5.10.1

Patch Changes

Changes

Testing

Docs

Description

Changes

Testing

Docs

Changes

Testing

Docs

Changes

Alternate Solution

Testing

Docs

Changes

Before

After

Testing

Docs

Changes

Docs

Changes

Testing

Docs

Changes

Testing

Docs

Changes

Testing

Docs

Releases

astro@5.10.0

Minor Changes

Usage

Migration from Experimental Responsive Images

Remove the experimental flag

Update image configuration options

Component usage remains the same

Live collections vs build-time collections

How to use

Patch Changes

@astrojs/cloudflare@12.6.0

Minor Changes

Patch Changes

@astrojs/vercel@8.2.0

Minor Changes

Patch Changes

Migration from Experimental Responsive Images

Remove the experimental flag

Update image configuration options

Component usage remains the same

Changes

Testing

Docs

Changes

Changes

@astrojs/underscore-redirects

@astrojs/netlify

Testing

Docs

Changes

Testing

Docs

Release Notes

Configuration

Release Notes

Bug fixes

Bug fixes

`@astrojs/underscore-redirects`

`@astrojs/netlify`