0
Fork 0
mirror of https://github.com/withastro/astro.git synced 2024-12-16 21:46:22 -05:00

[ci] release (#12567)

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This commit is contained in:
Houston (Bot) 2024-12-03 02:56:34 -08:00 committed by GitHub
parent bc18c3cfe2
commit fcdd37f684
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
184 changed files with 1702 additions and 1949 deletions

View file

@ -1,20 +0,0 @@
---
'astro': minor
---
Adapters can now specify the build output type they're intended for using the `adapterFeatures.buildOutput` property. This property can be used to always generate a server output, even if the project doesn't have any server-rendered pages.
```ts
{
'astro:config:done': ({ setAdapter, config }) => {
setAdapter({
name: 'my-adapter',
adapterFeatures: {
buildOutput: 'server',
},
});
},
}
```
If your adapter specifies `buildOutput: 'static'`, and the user's project contains server-rendered pages, Astro will warn in development and error at build time. Note that a hybrid output, containing both static and server-rendered pages, is considered to be a `server` output, as a server is required to serve the server-rendered pages.

View file

@ -1,9 +0,0 @@
---
'astro': major
---
Unflag globalRoutePriority
The previously experimental feature `globalRoutePriority` is now the default in Astro 5.
This was a refactoring of route prioritization in Astro, making it so that injected routes, file-based routes, and redirects are all prioritized using the same logic. This feature has been enabled for all Starlight projects since it was added and should not affect most users.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a bug where content types were not generated when first running astro dev unless src/content exists

View file

@ -1,14 +0,0 @@
---
'astro': patch
---
`render()` signature now takes `renderOptions` as 2nd argument
The signature for `app.render()` has changed, and the second argument is now an options object called `renderOptions` with more options for customizing rendering.
The `renderOptions` are:
- `addCookieHeader`: Determines whether Astro will set the `Set-Cookie` header, otherwise the adapter is expected to do so itself.
- `clientAddress`: The client IP address used to set `Astro.clientAddress`.
- `locals`: An object of locals that's set to `Astro.locals`.
- `routeData`: An object specifying the route to use.

View file

@ -1,30 +0,0 @@
---
'astro': minor
---
Adds experimental support for built-in SVG components.
This feature allows you to import SVG files directly into your Astro project as components. By default, Astro will inline the SVG content into your HTML output.
To enable this feature, set `experimental.svg` to `true` in your Astro config:
```js
{
experimental: {
svg: true,
},
}
```
To use this feature, import an SVG file in your Astro project, passing any common SVG attributes to the imported component. Astro also provides a `size` attribute to set equal `height` and `width` properties:
```astro
---
import Logo from './path/to/svg/file.svg';
---
<Logo size={24} />
```
For a complete overview, and to give feedback on this experimental API, see the [Feature RFC](https://github.com/withastro/roadmap/pull/1035).

View file

@ -1,21 +0,0 @@
---
'astro': major
---
### [changed]: `entryPoint` type inside the hook `astro:build:ssr`
In Astro v4.x, the `entryPoint` type was `RouteData`.
Astro v5.0 the `entryPoint` type is `IntegrationRouteData`, which contains a subset of the `RouteData` type. The fields `isIndex` and `fallbackRoutes` were removed.
#### What should I do?
Update your adapter to change the type of `entryPoint` from `RouteData` to `IntegrationRouteData`.
```diff
-import type {RouteData} from 'astro';
+import type {IntegrationRouteData} from "astro"
-function useRoute(route: RouteData) {
+function useRoute(route: IntegrationRouteData) {
}
```

View file

@ -1,5 +0,0 @@
---
'astro': major
---
Bumps Vite to ^6.0.1 and handles its breaking changes

View file

@ -1,5 +0,0 @@
---
'@astrojs/markdoc': patch
---
Uses latest version of `@astrojs/markdown-remark` with updated Shiki APIs

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a bug where content config was ignored if it was outside of content dir and has a parent dir with an underscore

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes an issue where an incorrect usage of Astro actions was lost when porting the fix from v4 to v5

View file

@ -1,5 +0,0 @@
---
"astro": major
---
The lowest version of Node supported by Astro is now Node v18.17.1 and higher.

View file

@ -1,15 +0,0 @@
---
'astro': major
---
Updates how the `build.client` and `build.server` option values get resolved to match existing documentation. With this fix, the option values will now correctly resolve relative to the `outDir` option. So if `outDir` is set to `./dist/nested/`, then by default:
- `build.client` will resolve to `<root>/dist/nested/client/`
- `build.server` will resolve to `<root>/dist/nested/server/`
Previously the values were incorrectly resolved:
- `build.client` was resolved to `<root>/dist/nested/dist/client/`
- `build.server` was resolved to `<root>/dist/nested/dist/server/`
If you were relying on the previous build paths, make sure that your project code is updated to the new build paths.

View file

@ -1,7 +0,0 @@
---
'astro': major
---
Adds a default exclude and include value to the tsconfig presets. `{projectDir}/dist` is now excluded by default, and `{projectDir}/.astro/types.d.ts` and `{projectDir}/**/*` are included by default.
Both of these options can be overridden by setting your own values to the corresponding settings in your `tsconfig.json` file.

View file

@ -1,13 +0,0 @@
---
'@astrojs/markdown-remark': major
'astro': major
---
Cleans up Astro-specfic metadata attached to `vfile.data` in Remark and Rehype plugins. Previously, the metadata was attached in different locations with inconsistent names. The metadata is now renamed as below:
- `vfile.data.__astroHeadings` -> `vfile.data.astro.headings`
- `vfile.data.imagePaths` -> `vfile.data.astro.imagePaths`
The types of `imagePaths` has also been updated from `Set<string>` to `string[]`. The `vfile.data.astro.frontmatter` metadata is left unchanged.
While we don't consider these APIs public, they can be accessed by Remark and Rehype plugins that want to re-use Astro's metadata. If you are using these APIs, make sure to access them in the new locations.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a bug where legacy content types were generated for content layer collections if they were in the content directory

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Correctly parse values returned from inline loader

View file

@ -1,25 +0,0 @@
---
'astro': major
---
The `locals` object can no longer be overridden
Middleware, API endpoints, and pages can no longer override the `locals` object in its entirety. You can still append values onto the object, but you can not replace the entire object and delete its existing values.
If you were previously overwriting like so:
```js
ctx.locals = {
one: 1,
two: 2
}
```
This can be changed to an assignment on the existing object instead:
```js
Object.assign(ctx.locals, {
one: 1,
two: 2
})
```

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes an issue where the refresh context data was not passed correctly to content layer loaders

View file

@ -1,45 +0,0 @@
---
'astro': patch
---
Adds a new function `refreshContent` to the `astro:server:setup` hook that allows integrations to refresh the content layer. This can be used, for example, to register a webhook endpoint during dev, or to open a socket to a CMS to listen for changes.
By default, `refreshContent` will refresh all collections. You can optionally pass a `loaders` property, which is an array of loader names. If provided, only collections that use those loaders will be refreshed. For example, A CMS integration could use this property to only refresh its own collections.
You can also pass a `context` object to the loaders. This can be used to pass arbitrary data, such as the webhook body, or an event from the websocket.
```ts
{
name: 'my-integration',
hooks: {
'astro:server:setup': async ({ server, refreshContent }) => {
server.middlewares.use('/_refresh', async (req, res) => {
if(req.method !== 'POST') {
res.statusCode = 405
res.end('Method Not Allowed');
return
}
let body = '';
req.on('data', chunk => {
body += chunk.toString();
});
req.on('end', async () => {
try {
const webhookBody = JSON.parse(body);
await refreshContent({
context: { webhookBody },
loaders: ['my-loader']
});
res.writeHead(200, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ message: 'Content refreshed successfully' }));
} catch (error) {
res.writeHead(500, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ error: 'Failed to refresh content: ' + error.message }));
}
});
});
}
}
}
```

View file

@ -1,5 +0,0 @@
---
'@astrojs/upgrade': patch
---
Fixes an issue where `@astrojs/upgrade` announces integration updates for already up to date packages

View file

@ -1,9 +0,0 @@
---
'@astrojs/mdx': major
---
Handles the breaking change in Astro where content pages (including `.mdx` pages located within `src/pages/`) no longer respond with `charset=utf-8` in the `Content-Type` header.
For MDX pages without layouts, `@astrojs/mdx` will automatically add the `<meta charset="utf-8">` tag to the page by default. This reduces the boilerplate needed to write with non-ASCII characters. If your MDX pages have a layout, the layout component should include the `<meta charset="utf-8">` tag.
If you require `charset=utf-8` to render your page correctly, make sure that your layout components have the `<meta charset="utf-8">` tag added.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Update error link to on-demand rendering guide

View file

@ -1,18 +0,0 @@
---
'astro': major
---
The `image.endpoint` config now allow customizing the route of the image endpoint in addition to the entrypoint. This can be useful in niche situations where the default route `/_image` conflicts with an existing route or your local server setup.
```js
import { defineConfig } from "astro/config";
defineConfig({
image: {
endpoint: {
route: "/image",
entrypoint: "./src/image_endpoint.ts"
}
},
})
```

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Prevents Vite emitting an error when restarting itself

View file

@ -1,14 +0,0 @@
---
'astro': major
'@astrojs/mdx': major
'@astrojs/markdown-remark': major
'@astrojs/db': minor
'@astrojs/web-vitals': major
'@astrojs/underscore-redirects': minor
---
Welcome to the Astro 5 beta! This release has no changes from the latest alpha of this package, but it does bring us one step closer to the final, stable release.
Starting from this release, no breaking changes will be introduced unless absolutely necessary.
To learn how to upgrade, check out the [Astro v5.0 upgrade guide in our beta docs site](https://5-0-0-beta.docs.astro.build/en/guides/upgrade-to/v5/).

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Handle multiple root nodes on SVG files

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Exports the `RenderResult` type

View file

@ -1,48 +0,0 @@
---
'astro': major
---
The `astro:env` feature introduced behind a flag in [v4.10.0](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md#x4100) is no longer experimental and is available for general use. If you have been waiting for stabilization before using `astro:env`, you can now do so.
This feature lets you configure a type-safe schema for your environment variables, and indicate whether they should be available on the server or the client.
To configure a schema, add the `env` option to your Astro config and define your client and server variables. If you were previously using this feature, please remove the experimental flag from your Astro config and move your entire `env` configuration unchanged to a top-level option.
```js
import { defineConfig, envField } from 'astro/config'
export default defineConfig({
env: {
schema: {
API_URL: envField.string({ context: "client", access: "public", optional: true }),
PORT: envField.number({ context: "server", access: "public", default: 4321 }),
API_SECRET: envField.string({ context: "server", access: "secret" }),
}
}
})
```
You can import and use your defined variables from the appropriate `/client` or `/server` module:
```astro
---
import { API_URL } from "astro:env/client"
import { API_SECRET_TOKEN } from "astro:env/server"
const data = await fetch(`${API_URL}/users`, {
method: "GET",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${API_SECRET_TOKEN}`
},
})
---
<script>
import { API_URL } from "astro:env/client"
fetch(`${API_URL}/ping`)
</script>
```
Please see our [guide to using environment variables](https://docs.astro.build/en/guides/environment-variables/#astroenv) for more about this feature.

View file

@ -1,5 +0,0 @@
---
'@astrojs/solid-js': patch
---
Updates vite-plugin-solid to handle Vite 6

View file

@ -1,14 +0,0 @@
---
'astro': minor
---
The following renderer fields and integration fields now accept `URL` as a type:
**Renderers**:
- `AstroRenderer.clientEntrpoint`
- `AstroRenderer.serverEntrypoint`
**Integrations**:
- `InjectedRoute.entrypoint`
- `AstroIntegrationMiddleware.entrypoint`
- `DevToolbarAppEntry.entrypoint`

View file

@ -1,5 +0,0 @@
---
'@astrojs/svelte': patch
---
Fixes an Reference Error that occurred during client transitions

View file

@ -1,5 +0,0 @@
---
'astro': minor
---
Updates to Vite 6.0.0-beta.6

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Explicitly import index.ts to fix types when moduleResolution is NodeNext

View file

@ -1,16 +0,0 @@
---
'@astrojs/markdoc': minor
'@astrojs/preact': minor
'@astrojs/svelte': minor
'@astrojs/react': minor
'@astrojs/solid-js': minor
'@astrojs/mdx': minor
'@astrojs/vue': minor
'create-astro': minor
'@astrojs/prism': minor
'@astrojs/telemetry': minor
'@astrojs/upgrade': minor
'astro': minor
---
Drops node 21 support

View file

@ -1,11 +0,0 @@
---
'astro': patch
---
Updates Astro's default `<script>` rendering strategy and removes the `experimental.directRenderScript` option as this is now the default behavior: scripts are always rendered directly. This new strategy prevents scripts from being executed in pages where they are not used.
Scripts will directly render as declared in Astro files (including existing features like TypeScript, importing `node_modules`, and deduplicating scripts). You can also now conditionally render scripts in your Astro file.
However, this means scripts are no longer hoisted to the `<head>`, multiple scripts on a page are no longer bundled together, and the `<script>` tag may interfere with the CSS styling.
As this is a potentially breaking change to your script behavior, please review your `<script>` tags and ensure that they behave as expected.

View file

@ -1,7 +0,0 @@
---
'astro': major
---
Removes the `assets` property on `supportedAstroFeatures` for adapters, as it did not reflect reality properly in many cases.
Now, relating to assets, only a single `sharpImageService` property is available, determining if the adapter is compatible with the built-in sharp image service.

View file

@ -1,5 +0,0 @@
---
'astro': minor
---
Improves `defineConfig` type safety. TypeScript will now error if a group of related configuration options do not have consistent types. For example, you will now see an error if your language set for `i18n.defaultLocale` is not one of the supported locales specified in `i18n.locales`.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a type and an example in documenting the `security.checkOrigin` property of Astro config.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Allows "slug" as a field in content layer data

View file

@ -1,21 +0,0 @@
---
'astro': major
---
### [changed]: `routes` type inside the hook `astro:build:done`
In Astro v4.x, the `routes` type was `RouteData`.
Astro v5.0 the `routes` type is `IntegrationRouteData`, which contains a subset of the `RouteData` type. The fields `isIndex` and `fallbackRoutes` were removed.
#### What should I do?
Update your adapter to change the type of `routes` from `RouteData` to `IntegrationRouteData`.
```diff
-import type {RouteData} from 'astro';
+import type {IntegrationRouteData} from "astro"
-function useRoute(route: RouteData) {
+function useRoute(route: IntegrationRouteData) {
}
```

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes an issue where the origin check middleware run for prendered pages

View file

@ -1,50 +0,0 @@
---
'astro': minor
---
Adds a new `astro:routes:resolved` hook to the Integration API. Also update the `astro:build:done` hook by deprecating `routes` and adding a new `assets` map.
When building an integration, you can now get access to routes inside the `astro:routes:resolved` hook:
```js
const integration = () => {
return {
name: 'my-integration',
hooks: {
'astro:routes:resolved': ({ routes }) => {
console.log(routes)
}
}
}
}
```
This hook runs before `astro:config:done`, and whenever a route changes in development.
The `routes` array from `astro:build:done` is now deprecated, and exposed properties are now available on `astro:routes:resolved`, except for `distURL`. For this, you can use the newly exposed `assets` map:
```diff
const integration = () => {
+ let routes
return {
name: 'my-integration',
hooks: {
+ 'astro:routes:resolved': (params) => {
+ routes = params.routes
+ },
'astro:build:done': ({
- routes
+ assets
}) => {
+ for (const route of routes) {
+ const distURL = assets.get(route.pattern)
+ if (distURL) {
+ Object.assign(route, { distURL })
+ }
+ }
console.log(routes)
}
}
}
}
```

View file

@ -1,21 +0,0 @@
---
'astro': major
---
Merges the `output: 'hybrid'` and `output: 'static'` configurations into one single configuration (now called `'static'`) that works the same way as the previous `hybrid` option.
It is no longer necessary to specify `output: 'hybrid'` in your Astro config to use server-rendered pages. The new `output: 'static'` has this capability included. Astro will now automatically provide the ability to opt out of prerendering in your static site with no change to your `output` configuration required. Any page route or endpoint can include `export const prerender = false` to be server-rendered, while the rest of your site is statically-generated.
If your project used hybrid rendering, you must now remove the `output: 'hybrid'` option from your Astro config as it no longer exists. However, no other changes to your project are required, and you should have no breaking changes. The previous `'hybrid'` behavior is now the default, under a new name `'static'`.
If you were using the `output: 'static'` (default) option, you can continue to use it as before. By default, all of your pages will continue to be prerendered and you will have a completely static site. You should have no breaking changes to your project.
```diff
import { defineConfig } from "astro/config";
export default defineConfig({
- output: 'hybrid',
});
```
An adapter is still required to deploy an Astro project with any server-rendered pages. Failure to include an adapter will result in a warning in development and an error at build time.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes and issue where `Astro.currentLocale` always returned the default locale when consumed inside a server island.

View file

@ -1,13 +0,0 @@
---
'astro': patch
---
Use GET requests with preloading for Server Islands
Server Island requests include the props used to render the island as well as any slots passed in (excluding the fallback slot). Since browsers have a max 4mb URL length we default to using a POST request to avoid overflowing this length.
However in reality most usage of Server Islands are fairly isolated and won't exceed this limit, so a GET request is possible by passing this same information via search parameters.
Using GET means we can also include a `<link rel="preload">` tag to speed up the request.
This change implements this, with safe fallback to POST.

View file

@ -1,6 +0,0 @@
---
'@astrojs/svelte': major
'@astrojs/vue': major
---
Updates peer dependency range to support Astro 5

View file

@ -1,102 +0,0 @@
---
'astro': minor
---
The Content Layer API introduced behind a flag in [4.14.0](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md#4140) is now stable and ready for use in Astro v5.0.
The new Content Layer API builds upon content collections, taking them beyond local files in `src/content/` and allowing you to fetch content from anywhere, including remote APIs. These new collections work alongside your existing content collections, and you can migrate them to the new API at your own pace. There are significant improvements to performance with large collections of local files. For more details, see [the Content Layer RFC](https://github.com/withastro/roadmap/blob/content-layer/proposals/0050-content-layer.md).
If you previously used this feature, you can now remove the `experimental.contentLayer` flag from your Astro config:
```diff
// astro.config.mjs
import { defineConfig } from 'astro'
export default defineConfig({
- experimental: {
- contentLayer: true
- }
})
```
### Loading your content
The core of the new Content Layer API is the loader, a function that fetches content from a source and caches it in a local data store. Astro 4.14 ships with built-in `glob()` and `file()` loaders to handle your local Markdown, MDX, Markdoc, and JSON files:
```ts {3,7}
// src/content/config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';
const blog = defineCollection({
// The ID is a slug generated from the path of the file relative to `base`
loader: glob({ pattern: "**/*.md", base: "./src/data/blog" }),
schema: z.object({
title: z.string(),
description: z.string(),
publishDate: z.coerce.date(),
})
});
export const collections = { blog };
```
You can then query using the existing content collections functions, and use a simplified `render()` function to display your content:
```astro
---
import { getEntry, render } from 'astro:content';
const post = await getEntry('blog', Astro.params.slug);
const { Content } = await render(entry);
---
<Content />
```
### Creating a loader
You're not restricted to the built-in loaders we hope you'll try building your own. You can fetch content from anywhere and return an array of entries:
```ts
// src/content/config.ts
const countries = defineCollection({
loader: async () => {
const response = await fetch("https://restcountries.com/v3.1/all");
const data = await response.json();
// Must return an array of entries with an id property,
// or an object with IDs as keys and entries as values
return data.map((country) => ({
id: country.cca3,
...country,
}));
},
// optionally add a schema to validate the data and make it type-safe for users
// schema: z.object...
});
export const collections = { countries };
```
For more advanced loading logic, you can define an object loader. This allows incremental updates and conditional loading, and gives full access to the data store. It also allows a loader to define its own schema, including generating it dynamically based on the source API. See the [the Content Layer API RFC](https://github.com/withastro/roadmap/blob/content-layer/proposals/0050-content-layer.md#loaders) for more details.
### Sharing your loaders
Loaders are better when they're shared. You can create a package that exports a loader and publish it to npm, and then anyone can use it on their site. We're excited to see what the community comes up with! To get started, [take a look at some examples](https://github.com/ascorbic/astro-loaders/). Here's how to load content using an RSS/Atom feed loader:
```ts
// src/content/config.ts
import { defineCollection } from "astro:content";
import { feedLoader } from "@ascorbic/feed-loader";
const podcasts = defineCollection({
loader: feedLoader({
url: "https://feeds.99percentinvisible.org/99percentinvisible",
}),
});
export const collections = { podcasts };
```
To learn more, see [the Content Layer RFC](https://github.com/withastro/roadmap/blob/content-layer/proposals/0050-content-layer.md).

View file

@ -1,11 +0,0 @@
---
'astro': minor
---
ViewTransitions component renamed to ClientRouter
The `<ViewTransitions />` component has been renamed to `<ClientRouter />`. There are no other changes than the name. The old name will continue to work in Astro 5.x, but will be removed in 6.0.
This change was done to clarify the role of the component within Astro's View Transitions support. Astro supports View Transitions APIs in a few different ways, and renaming the component makes it more clear that the features you get from the ClientRouter component are slightly different from what you get using the native CSS-based MPA router.
We still intend to maintain the ClientRouter as before, and it's still important for use-cases that the native support doesn't cover, such as persisting state between pages.

View file

@ -1,23 +0,0 @@
---
'astro': patch
---
Adds support for array patterns in the built-in `glob()` content collections loader
The glob loader can now accept an array of multiple patterns as well as string patterns. This allows you to more easily combine multiple patterns into a single collection, and also means you can use negative matches to exclude files from the collection.
```ts
const probes = defineCollection({
// Load all markdown files in the space-probes directory, except for those that start with "voyager-"
loader: glob({ pattern: ['*.md', '!voyager-*'], base: 'src/data/space-probes' }),
schema: z.object({
name: z.string(),
type: z.enum(['Space Probe', 'Mars Rover', 'Comet Lander']),
launch_date: z.date(),
status: z.enum(['Active', 'Inactive', 'Decommissioned']),
destination: z.string(),
operator: z.string(),
notable_discoveries: z.array(z.string()),
}),
});
```

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Properly handle including trailing slash on the image endpoint route based on the trailingSlash config

View file

@ -1,5 +0,0 @@
---
'@astrojs/markdown-remark': major
---
Updates return object of `createShikiHighlighter` as `codeToHast` and `codeToHtml` to allow generating either the hast or html string directly

View file

@ -1,17 +0,0 @@
---
'astro': major
---
Updates the default value of `security.checkOrigin` to `true`, which enables Cross-Site Request Forgery (CSRF) protection by default for pages rendered on demand.
If you had previously configured `security.checkOrigin: true`, you no longer need this set in your Astro config. This is now the default and it is safe to remove.
To disable this behavior and opt out of automatically checking that the “origin” header matches the URL sent by each request, you must explicitly set `security.checkOrigin: false`:
```diff
export default defineConfig({
+ security: {
+ checkOrigin: false
+ }
})
```

View file

@ -1,9 +0,0 @@
---
'astro': major
---
Updates internal Shiki rehype plugin to highlight code blocks as hast (using Shiki's `codeToHast()` API). This allows a more direct Markdown and MDX processing, and improves the performance when building the project, but may cause issues with existing Shiki transformers.
If you are using Shiki transformers passed to `markdown.shikiConfig.transformers`, you must make sure they do not use the `postprocess` hook as it no longer runs on code blocks in `.md` and `.mdx` files. (See [the Shiki documentation on transformer hooks](https://shiki.style/guide/transformers#transformer-hooks) for more information).
Code blocks in `.mdoc` files and `<Code />` component do not use the internal Shiki rehype plugin and are unaffected.

View file

@ -1,5 +0,0 @@
---
'@astrojs/svelte': major
---
Updates `@sveltejs/vite-plugin-svelte` to v5 to handle Vite 6

View file

@ -1,7 +0,0 @@
---
'astro': patch
---
Fixes a bug where configured redirects were incorrectly constructed when reading the file system.
This caused an issue where configuring a redirect in `astro.config.mjs` like `{ /old: /new }`, failed to trigger the correct redirect in the dev server.

View file

@ -1,22 +0,0 @@
---
'astro': minor
---
Adds a new property `isPrerendered` to the globals `Astro` and `APIContext` . This boolean value represents whether or not the current page is prerendered:
```astro
---
// src/pages/index.astro
export const prerender = true
---
```
```js
// src/middleware.js
export const onRequest = (ctx, next) => {
console.log(ctx.isPrerendered) // it will log true
return next()
}
```

View file

@ -1,19 +0,0 @@
---
'astro': major
---
Deprecate Astro.glob
The `Astro.glob` function has been deprecated in favor of Content Collections and `import.meta.glob`.
- If you want to query for markdown and MDX in your project, use Content Collections.
- If you want to query source files in your project, use `import.meta.glob`(https://vitejs.dev/guide/features.html#glob-import).
Also consider using glob packages from npm, like [fast-glob](https://www.npmjs.com/package/fast-glob), especially if statically generating your site, as it is faster for most use-cases.
The easiest path is to migrate to `import.meta.glob` like so:
```diff
- const posts = Astro.glob('./posts/*.md');
+ const posts = Object.values(import.meta.glob('./posts/*.md', { eager: true }));
```

View file

@ -1,7 +0,0 @@
---
'astro': major
---
The command `astro add vercel` now updates the configuration file differently, and adds `@astrojs/vercel` as module to import.
This is a breaking change because it requires the version `8.*` of `@astrojs/vercel`.

View file

@ -1,68 +0,0 @@
---
'astro': minor
---
Adds a new optional `parser` property to the built-in `file()` loader for content collections to support additional file types such as `toml` and `csv`.
The `file()` loader now accepts a second argument that defines a `parser` function. This allows you to specify a custom parser (e.g. `toml.parse` or `csv-parse`) to create a collection from a file's contents. The `file()` loader will automatically detect and parse JSON and YAML files (based on their file extension) with no need for a `parser`.
This works with any type of custom file formats including `csv` and `toml`. The following example defines a content collection `dogs` using a `.toml` file.
```toml
[[dogs]]
id = "..."
age = "..."
[[dogs]]
id = "..."
age = "..."
```
After importing TOML's parser, you can load the `dogs` collection into your project by passing both a file path and `parser` to the `file()` loader.
```typescript
import { defineCollection } from "astro:content"
import { file } from "astro/loaders"
import { parse as parseToml } from "toml"
const dogs = defineCollection({
loader: file("src/data/dogs.toml", { parser: (text) => parseToml(text).dogs }),
schema: /* ... */
})
// it also works with CSVs!
import { parse as parseCsv } from "csv-parse/sync";
const cats = defineCollection({
loader: file("src/data/cats.csv", { parser: (text) => parseCsv(text, { columns: true, skipEmptyLines: true })})
});
```
The `parser` argument also allows you to load a single collection from a nested JSON document. For example, this JSON file contains multiple collections:
```json
{"dogs": [{}], "cats": [{}]}
```
You can seperate these collections by passing a custom `parser` to the `file()` loader like so:
```typescript
const dogs = defineCollection({
loader: file("src/data/pets.json", { parser: (text) => JSON.parse(text).dogs })
});
const cats = defineCollection({
loader: file("src/data/pets.json", { parser: (text) => JSON.parse(text).cats })
});
```
And it continues to work with maps of `id` to `data`
```yaml
bubbles:
breed: "Goldfish"
age: 2
finn:
breed: "Betta"
age: 1
```
```typescript
const fish = defineCollection({
loader: file("src/data/fish.yaml"),
schema: z.object({ breed: z.string(), age: z.number() })
});
```

View file

@ -1,14 +0,0 @@
---
'astro': major
---
Removes internal JSX handling and moves the responsibility to the `@astrojs/mdx` package directly. The following exports are also now removed:
- `astro/jsx/babel.js`
- `astro/jsx/component.js`
- `astro/jsx/index.js`
- `astro/jsx/renderer.js`
- `astro/jsx/server.js`
- `astro/jsx/transform-options.js`
If your project includes `.mdx` files, you must upgrade `@astrojs/mdx` to the latest version so that it doesn't rely on these entrypoints to handle your JSX.

View file

@ -1,6 +0,0 @@
---
'astro': patch
---
Exports types for all `LoaderContext` properties from `astro/loaders` to make it easier to use them in custom loaders.
The `ScopedDataStore` interface (which was previously internal) is renamed to `DataStore`, to reflect the fact that it's the only public API for the data store.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a bug where the params weren't correctly computed when rendering URLs with non-English characters

View file

@ -1,16 +0,0 @@
---
'astro': major
---
Makes the `compiledContent` property of Markdown content an async function, this change should fix underlying issues where sometimes when using a custom image service and images inside Markdown, Node would exit suddenly without any error message.
```diff
---
import * as myPost from "../post.md";
- const content = myPost.compiledContent();
+ const content = await myPost.compiledContent();
---
<Fragment set:html={content} />
```

View file

@ -1,11 +0,0 @@
---
'astro': major
---
Updates the Astro config loading flow to ignore processing locally-linked dependencies with Vite (e.g. `npm link`, in a monorepo, etc). Instead, they will be normally imported by the Node.js runtime the same way as other dependencies from `node_modules`.
Previously, Astro would process locally-linked dependencies which were able to use Vite features like TypeScript when imported by the Astro config file.
However, this caused confusion as integration authors may test against a package that worked locally, but not when published. This method also restricts using CJS-only dependencies because Vite requires the code to be ESM. Therefore, Astro's behaviour is now changed to ignore processing any type of dependencies by Vite.
In most cases, make sure your locally-linked dependencies are built to JS before running the Astro project, and the config loading should work as before.

View file

@ -1,25 +0,0 @@
---
'astro': minor
---
Adds a new property to the globals `Astro` and `APIContext` called `routePattern`. The `routePattern` represents the current route (component)
that is being rendered by Astro. It's usually a path pattern will look like this: `blog/[slug]`:
```astro
---
// src/pages/blog/[slug].astro
const route = Astro.routePattern;
console.log(route); // it will log "blog/[slug]"
---
```
```js
// src/pages/index.js
export const GET = (ctx) => {
console.log(ctx.routePattern) // it will log src/pages/index.js
return new Response.json({ loreum: "ipsum" })
}
```

View file

@ -1,11 +0,0 @@
---
'astro': major
---
Prevent usage of `astro:content` in the client
Usage of `astro:content` in the client has always been discouraged because it leads to all of your content winding up in your client bundle, and can possibly leaks secrets.
This formally makes doing so impossible, adding to the previous warning with errors.
In the future Astro might add APIs for client-usage based on needs.

View file

@ -1,5 +0,0 @@
---
'astro': major
---
Bumps `vite` dependency to v6.0.0-beta.2. The version is pinned and will be updated as new Vite versions publish to prevent unhandled breaking changes. For the full list of Vite-specific changes, see [its changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md).

View file

@ -1,10 +0,0 @@
---
'create-astro': minor
---
Reworks the experience of creating a new Astro project using the `create astro` CLI command.
- Updates the list of templates to include Starlight and combines the "minimal" and "basics" templates into a new, refreshed "Basics" template to serve as the single, minimal Astro project starter.
- Removes the TypeScript question. Astro is TypeScript-only, so this question was often misleading. The "Strict" preset is now the default, but it can still be changed manually in `tsconfig.json`.
- `astro check` is no longer automatically added to the build script.
- Added a new `--add` flag to install additional integrations after creating a project. For example, `pnpm create astro --add react` will create a new Astro project and install the React integration.

View file

@ -1,19 +0,0 @@
---
'astro': major
---
Changes the default `tsconfig.json` with better defaults, and makes `src/env.d.ts` optional
Astro's default `tsconfig.json` in starter examples has been updated to include generated types and exclude your build output. This means that `src/env.d.ts` is only necessary if you have added custom type declarations or if you're not using a `tsconfig.json` file.
Additionally, running `astro sync` no longer creates, nor updates, `src/env.d.ts` as it is not required for type-checking standard Astro projects.
To update your project to Astro's recommended TypeScript settings, please add the following `include` and `exclude` properties to `tsconfig.json`:
```diff
{
"extends": "astro/tsconfigs/base",
+ "include": [".astro/types.d.ts", "**/*"],
+ "exclude": ["dist"]
}
```

View file

@ -1,7 +0,0 @@
---
'@astrojs/mdx': minor
---
Updates adapter server entrypoint to use `@astrojs/mdx/server.js`
This is an internal change. Handling JSX in your `.mdx` files has been moved from Astro internals and is now the responsibility of this integration. You should not notice a change in your project, and no update to your code is required.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Updates the `env` configuration reference docs to include a full API reference for `envField`.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes a bug where a catchall route would match an image endpoint request

View file

@ -1,5 +0,0 @@
---
'@astrojs/underscore-redirects': minor
---
Updates the type from `RouteData` to `IntegrationRouteData`

View file

@ -1,7 +0,0 @@
---
'astro': minor
---
Adds a new `buildOutput` property to the `astro:config:done` hook returning the build output type.
This can be used to know if the user's project will be built as a static site (HTML files), or a server-rendered site (whose exact output depends on the adapter).

View file

@ -1,7 +0,0 @@
---
'astro': major
---
Refactor the exported types from the `astro` module. There should normally be no breaking changes, but if you relied on some previously deprecated types, these might now have been fully removed.
In most cases, updating your code to move away from previously deprecated APIs in previous versions of Astro should be enough to fix any issues.

View file

@ -1,7 +0,0 @@
---
'@astrojs/studio': patch
'astro': patch
'@astrojs/db': patch
---
Replaces `ora` with `yocto-spinner`

View file

@ -1,146 +0,0 @@
{
"mode": "exit",
"tag": "beta",
"initialVersions": {
"astro": "5.0.0-alpha.9",
"@astrojs/prism": "3.1.0",
"@astrojs/rss": "4.0.7",
"create-astro": "4.9.0",
"@astrojs/db": "0.13.2-alpha.1",
"@astrojs/alpinejs": "0.4.0",
"@astrojs/markdoc": "0.11.4",
"@astrojs/mdx": "4.0.0-alpha.2",
"@astrojs/partytown": "2.1.2",
"@astrojs/preact": "3.5.3",
"@astrojs/react": "3.6.2",
"@astrojs/sitemap": "3.1.6",
"@astrojs/solid-js": "4.4.1",
"@astrojs/svelte": "5.7.0",
"@astrojs/tailwind": "5.1.0",
"@astrojs/vue": "4.5.0",
"@astrojs/web-vitals": "2.0.1-alpha.0",
"@astrojs/internal-helpers": "0.4.1",
"@astrojs/markdown-remark": "6.0.0-alpha.1",
"@astrojs/studio": "0.1.1",
"@astrojs/telemetry": "3.1.0",
"@astrojs/underscore-redirects": "0.4.0-alpha.0",
"@astrojs/upgrade": "0.3.3",
"@astrojs/cloudflare": "0.0.0",
"@astrojs/netlify": "0.0.0",
"@astrojs/node": "0.0.0",
"@astrojs/vercel": "0.0.0"
},
"changesets": [
"afraid-apricots-buy",
"blue-boats-relax",
"blue-sloths-stare",
"blue-socks-doubt",
"brave-elephants-fly",
"breezy-brooms-count",
"breezy-colts-promise",
"bright-keys-sell",
"brown-bulldogs-share",
"chatty-teachers-sit",
"chilly-terms-know",
"clean-camels-drive",
"clean-donuts-walk",
"clean-moles-rest",
"cold-bananas-hear",
"cool-mangos-shop",
"cuddly-shoes-press",
"curvy-walls-kneel",
"dirty-cooks-explode",
"dry-lamps-smile",
"dry-worms-knock",
"dull-moles-talk",
"eight-days-sort",
"eight-seahorses-attend",
"eighty-bags-cross",
"eighty-boxes-applaud",
"eighty-crabs-cross",
"eighty-donkeys-fly",
"eighty-ligers-punch",
"empty-houses-melt",
"fair-ears-compare",
"five-jars-hear",
"fluffy-jars-live",
"forty-trains-notice",
"fresh-pandas-drive",
"funny-wolves-dream",
"fuzzy-pugs-live",
"gentle-scissors-bow",
"giant-ravens-look",
"giant-rocks-thank",
"gorgeous-foxes-divide",
"healthy-ads-scream",
"heavy-peas-sneeze",
"heavy-seahorses-poke",
"hip-wombats-exercise",
"honest-dingos-add",
"hot-camels-move",
"hungry-jokes-try",
"itchy-toys-march",
"large-zebras-sniff",
"lemon-frogs-wait",
"light-pears-accept",
"long-lions-do",
"long-months-rule",
"loud-cougars-grow",
"lovely-pianos-breathe",
"many-garlics-lick",
"mean-donkeys-switch",
"metal-birds-admire",
"modern-bears-deny",
"moody-waves-think",
"nasty-crabs-worry",
"neat-dots-hear",
"neat-queens-learn",
"old-actors-learn",
"old-zebras-teach",
"perfect-fans-fly",
"pink-yaks-exercise",
"polite-roses-fail",
"poor-dots-add",
"poor-frogs-dream",
"poor-seals-clap",
"pretty-walls-camp",
"proud-games-repair",
"proud-terms-swim",
"quick-ads-exercise",
"quick-onions-leave",
"red-paws-juggle",
"rotten-dodos-judge",
"rotten-phones-scream",
"selfish-cats-crash",
"selfish-impalas-grin",
"sharp-worms-sniff",
"sixty-coins-worry",
"sixty-fishes-flow",
"sixty-oranges-walk",
"slimy-jeans-train",
"slimy-mice-dance",
"slimy-queens-hang",
"small-ties-sort",
"smooth-panthers-heal",
"spotty-garlics-cheat",
"strange-sheep-film",
"strong-months-grab",
"sweet-timers-smash",
"tall-waves-impress",
"tame-pumpkins-swim",
"tame-rats-cross",
"ten-students-repair",
"ten-walls-tap",
"thirty-clocks-jump",
"three-days-cough",
"three-olives-reflect",
"tough-planets-dress",
"twelve-comics-march",
"twenty-cobras-push",
"unlucky-bobcats-sit",
"violet-goats-grab",
"wet-foxes-walk",
"wise-carrots-float",
"young-terms-hammer"
]
}

View file

@ -1,5 +0,0 @@
---
'@astrojs/svelte': patch
---
New release to include changes from 5.7.3

View file

@ -1,7 +0,0 @@
---
'astro': patch
---
Adds an error when `Astro.rewrite()` is used to rewrite an on-demand route with a static route when using the `"server"` output.
This is a forbidden rewrite because Astro can't retrieve the emitted static route at runtime. This route is served by the hosting platform, and not Astro itself.

View file

@ -1,90 +0,0 @@
---
'astro': minor
---
Adds experimental support for automatic responsive images
This feature is experimental and may change in future versions. To enable it, set `experimental.responsiveImages` to `true` in your `astro.config.mjs` file.
```js title=astro.config.mjs
{
experimental: {
responsiveImages: true,
},
}
```
When this flag is enabled, you can pass a `layout` prop to any `<Image />` or `<Picture />` component to create a responsive image. When a layout is set, images have automatically generated `srcset` and `sizes` attributes based on the image's dimensions and the layout type. Images with `responsive` and `full-width` layouts will have styles applied to ensure they resize according to their container.
```astro
---
import { Image, Picture } from 'astro:assets';
import myImage from '../assets/my_image.png';
---
<Image src={myImage} alt="A description of my image." layout='responsive' width={800} height={600} />
<Picture src={myImage} alt="A description of my image." layout='full-width' formats={['avif', 'webp', 'jpeg']} />
```
This `<Image />` component will generate the following HTML output:
```html title=Output
<img
src="/_astro/my_image.hash3.webp"
srcset="/_astro/my_image.hash1.webp 640w,
/_astro/my_image.hash2.webp 750w,
/_astro/my_image.hash3.webp 800w,
/_astro/my_image.hash4.webp 828w,
/_astro/my_image.hash5.webp 1080w,
/_astro/my_image.hash6.webp 1280w,
/_astro/my_image.hash7.webp 1600w"
alt="A description of my image"
sizes="(min-width: 800px) 800px, 100vw"
loading="lazy"
decoding="async"
fetchpriority="auto"
width="800"
height="600"
style="--w: 800; --h: 600; --fit: cover; --pos: center;"
data-astro-image="responsive"
>
```
#### Responsive image properties
These are additional properties available to the `<Image />` and `<Picture />` components when responsive images are enabled:
- `layout`: The layout type for the image. Can be `responsive`, `fixed`, `full-width` or `none`. Defaults to value of `image.experimentalLayout`.
- `fit`: Defines how the image should be cropped if the aspect ratio is changed. Values match those of CSS `object-fit`. Defaults to `cover`, or the value of `image.experimentalObjectFit` if set.
- `position`: Defines the position of the image crop if the aspect ratio is changed. Values match those of CSS `object-position`. Defaults to `center`, or the value of `image.experimentalObjectPosition` if set.
- `priority`: If set, eagerly loads the image. Otherwise images will be lazy-loaded. Use this for your largest above-the-fold image. Defaults to `false`.
#### Default responsive image settings
You can enable responsive images for all `<Image />` and `<Picture />` components by setting `image.experimentalLayout` with a default value. This can be overridden by the `layout` prop on each component.
**Example:**
```js title=astro.config.mjs
{
image: {
// Used for all `<Image />` and `<Picture />` components unless overridden
experimentalLayout: 'responsive',
},
experimental: {
responsiveImages: true,
},
}
```
```astro
---
import { Image } from 'astro:assets';
import myImage from '../assets/my_image.png';
---
<Image src={myImage} alt="This will use responsive layout" width={800} height={600} />
<Image src={myImage} alt="This will use full-width layout" layout="full-width" />
<Image src={myImage} alt="This will disable responsive images" layout="none" />
```
For a complete overview, and to give feedback on this experimental API, see the [Responsive Images RFC](https://github.com/withastro/roadmap/blob/responsive-images/proposals/0053-responsive-images.md).

View file

@ -1,10 +0,0 @@
---
'@astrojs/markdown-remark': major
---
Renames the following CSS variables theme color token names to better align with the Shiki v1 defaults:
- `--astro-code-color-text` => `--astro-code-foreground`
- `--astro-code-color-background` => `--astro-code-background`
You can perform a global find and replace in your project to migrate to the new token names.

View file

@ -1,47 +0,0 @@
---
'astro': major
---
Refactors legacy `content` and `data` collections to use the Content Layer API `glob()` loader for better performance and to support backwards compatibility. Also introduces the `legacy.collections` flag for projects that are unable to update to the new behavior immediately.
:warning: **BREAKING CHANGE FOR LEGACY CONTENT COLLECTIONS** :warning:
By default, collections that use the old types (`content` or `data`) and do not define a `loader` are now implemented under the hood using the Content Layer API's built-in `glob()` loader, with extra backward-compatibility handling.
In order to achieve backwards compatibility with existing `content` collections, the following have been implemented:
- a `glob` loader collection is defined, with patterns that match the previous handling (matches `src/content/<collection name>/**/*.md` and other content extensions depending on installed integrations, with underscore-prefixed files and folders ignored)
- When used in the runtime, the entries have an ID based on the filename in the same format as legacy collections
- A `slug` field is added with the same format as before
- A `render()` method is added to the entry, so they can be called using `entry.render()`
- `getEntryBySlug` is supported
In order to achieve backwards compatibility with existing `data` collections, the following have been implemented:
- a `glob` loader collection is defined, with patterns that match the previous handling (matches `src/content/<collection name>/**/*{.json,.yaml}` and other data extensions, with underscore-prefixed files and folders ignored)
- Entries have an ID that is not slugified
- `getDataEntryById` is supported
While this backwards compatibility implementation is able to emulate most of the features of legacy collections, **there are some differences and limitations that may cause breaking changes to existing collections**:
- In previous versions of Astro, collections would be generated for all folders in `src/content/`, even if they were not defined in `src/content/config.ts`. This behavior is now deprecated, and collections should always be defined in `src/content/config.ts`. For existing collections, these can just be empty declarations (e.g. `const blog = defineCollection({})`) and Astro will implicitly define your legacy collection for you in a way that is compatible with the new loading behavior.
- The special `layout` field is not supported in Markdown collection entries. This property is intended only for standalone page files located in `src/pages/` and not likely to be in your collection entries. However, if you were using this property, you must now create dynamic routes that include your page styling.
- Sort order of generated collections is non-deterministic and platform-dependent. This means that if you are calling `getCollection()`, the order in which entries are returned may be different than before. If you need a specific order, you should sort the collection entries yourself.
- `image().refine()` is not supported. If you need to validate the properties of an image you will need to do this at runtime in your page or component.
- the `key` argument of `getEntry(collection, key)` is typed as `string`, rather than having types for every entry.
A new legacy configuration flag `legacy.collections` is added for users that want to keep their current legacy (content and data) collections behavior (available in Astro v2 - v4), or who are not yet ready to update their projects:
```js
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
legacy: {
collections: true
}
});
```
When set, no changes to your existing collections are necessary, and the restrictions on storing both new and old collections continue to exist: legacy collections (only) must continue to remain in `src/content/`, while new collections using a loader from the Content Layer API are forbidden in that folder.

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fix SVG Component sprite references

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Call server island early so it can set headers

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes actions with large amount of validation errors

View file

@ -1,5 +0,0 @@
---
'@astrojs/markdown-remark': major
---
Removes `InvalidAstroDataError`, `safelyGetAstroData`, and `setVfileFrontmatter` APIs in favour of `isFrontmatterValid`

View file

@ -1,6 +0,0 @@
---
'@astrojs/vercel': major
'@astrojs/node': major
---
Adds stable support for `astro:env`

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Updates error messages that assume content collections are located in `src/content/` with more generic language

View file

@ -1,31 +0,0 @@
---
'astro': minor
---
Adds support for passing values other than `"production"` or `"development"` to the `--mode` flag (e.g. `"staging"`, `"testing"`, or any custom value) to change the value of `import.meta.env.MODE` or the loaded `.env` file. This allows you take advantage of Vite's [mode](https://vite.dev/guide/env-and-mode#modes) feature.
Also adds a new `--devOutput` flag for `astro build` that will output a development-based build.
Note that changing the `mode` does not change the kind of code transform handled by Vite and Astro:
- In `astro dev`, Astro will transform code with debug information.
- In `astro build`, Astro will transform code with the most optimized output and removes debug information.
- In `astro build --devOutput` (new flag), Astro will transform code with debug information like in `astro dev`.
This enables various usecases like:
```bash
# Run the dev server connected to a "staging" API
astro dev --mode staging
# Build a site that connects to a "staging" API
astro build --mode staging
# Build a site that connects to a "production" API with additional debug information
astro build --devOutput
# Build a site that connects to a "testing" API
astro build --mode testing
```
The different modes can be used to load different `.env` files, e.g. `.env.staging` or `.env.production`, which can be customized for each environment, for example with different `API_URL` environment variable values.

View file

@ -1,6 +0,0 @@
---
'@astrojs/react': minor
'astro': minor
---
Changes the generated URL query param from `_astroAction` to `_action` when submitting a form using Actions. This avoids leaking the framework name into the URL bar, which may be considered a security issue.

View file

@ -1,7 +0,0 @@
---
'astro': patch
---
Resolves image paths in content layer with initial slash as project-relative
When using the `image()` schema helper, previously paths with an initial slash were treated as public URLs. This was to match the behavior of markdown images. However this is a change from before, where paths with an initial slash were treated as project-relative. This change restores the previous behavior, so that paths with an initial slash are treated as project-relative.

View file

@ -1,9 +0,0 @@
---
'@astrojs/preact': major
'@astrojs/svelte': major
'@astrojs/react': major
'@astrojs/solid-js': major
'@astrojs/vue': major
---
Updates Vite dependency to v6 to match Astro v5

View file

@ -1,5 +0,0 @@
---
'astro': patch
---
Fixes use of Vitest with Astro 5

View file

@ -1,7 +0,0 @@
---
'astro': minor
---
The value of the different properties on `supportedAstroFeatures` for adapters can now be objects, with a `support` and `message` properties. The content of the `message` property will be shown in the Astro CLI when the adapter is not compatible with the feature, allowing one to give a better informational message to the user.
This is notably useful with the new `limited` value, to explain to the user why support is limited.

View file

@ -1,50 +0,0 @@
---
'astro': major
---
Fixes attribute rendering for non-[boolean HTML attributes](https://developer.mozilla.org/en-US/docs/Glossary/Boolean/HTML) with boolean values to match proper attribute handling in browsers.
Previously, non-boolean attributes may not have included their values when rendered to HTML. In Astro v5.0, the values are now explicitly rendered as `="true"` or `="false"`
In the following `.astro` examples, only `allowfullscreen` is a boolean attribute:
```astro
<!-- src/pages/index.astro -->
<!-- `allowfullscreen` is a boolean attribute -->
<p allowfullscreen={true}></p>
<p allowfullscreen={false}></p>
<!-- `inherit` is *not* a boolean attribute -->
<p inherit={true}></p>
<p inherit={false}></p>
<!-- `data-*` attributes are not boolean attributes -->
<p data-light={true}></p>
<p data-light={false}></p>
```
Astro v5.0 now preserves the full data attribute with its value when rendering the HTML of non-boolean attributes:
```diff
<p allowfullscreen></p>
<p></p>
<p inherit="true"></p>
- <p inherit></p>
+ <p inherit="false"></p>
- <p data-light></p>
+ <p data-light="true"></p>
- <p></p>
+ <p data-light="false"></p>
```
If you rely on attribute values, for example to locate elements or to conditionally render, update your code to match the new non-boolean attribute values:
```diff
- el.getAttribute('inherit') === ''
+ el.getAttribute('inherit') === 'false'
- el.hasAttribute('data-light')
+ el.dataset.light === 'true'
```

View file

@ -1,5 +0,0 @@
---
'astro': minor
---
`astro add` no longer automatically sets `output: 'server'`. Since the default value of output now allows for server-rendered pages, it no longer makes sense to default to full server builds when you add an adapter

View file

@ -1,22 +0,0 @@
---
'@astrojs/vercel': major
'@astrojs/node': major
'astro': major
---
Removed support for the Squoosh image service. As the underlying library `libsquoosh` is no longer maintained, and the image service sees very little usage we have decided to remove it from Astro.
Our recommendation is to use the base Sharp image service, which is more powerful, faster, and more actively maintained.
```diff
- import { squooshImageService } from "astro/config";
import { defineConfig } from "astro/config";
export default defineConfig({
- image: {
- service: squooshImageService()
- }
});
```
If you are using this service, and cannot migrate to the base Sharp image service, a third-party extraction of the previous service is available here: https://github.com/Princesseuh/astro-image-service-squoosh

View file

@ -1,40 +0,0 @@
---
'astro': minor
---
[Server Islands](https://astro.build/blog/future-of-astro-server-islands/) introduced behind an experimental flag in [v4.12.0](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md#4120) is no longer experimental and is available for general use.
Server islands are Astro's solution for highly cacheable pages of mixed static and dynamic content. They allow you to specify components that should run on the server, allowing the rest of the page to be more aggressively cached, or even generated statically.
Turn any `.astro` component into a server island by adding the `server:defer` directive and optionally, fallback placeholder content. It will be rendered dynamically at runtime outside the context of the rest of the page, allowing you to add longer cache headers for the pages, or even prerender them.
```astro
---
import Avatar from '../components/Avatar.astro';
import GenericUser from '../components/GenericUser.astro';
---
<header>
<h1>Page Title</h1>
<div class="header-right">
<Avatar server:defer>
<GenericUser slot="fallback" />
</Avatar>
</div>
</header>
```
If you were previously using this feature, please remove the experimental flag from your Astro config:
```diff
import { defineConfig } from 'astro/config';
export default defineConfig({
experimental {
- serverIslands: true,
},
});
```
If you have been waiting for stabilization before using server islands, you can now do so.
Please see the [server island documentation](https://docs.astro.build/en/guides/server-islands/) for more about this feature.

View file

@ -1,11 +0,0 @@
---
'astro': major
---
Updates the automatic `charset=utf-8` behavior for Markdown pages, where instead of responding with `charset=utf-8` in the `Content-Type` header, Astro will now automatically add the `<meta charset="utf-8">` tag instead.
This behaviour only applies to Markdown pages (`.md` or similar Markdown files located within `src/pages/`) that do not use Astro's special `layout` frontmatter property. It matches the rendering behaviour of other non-content pages, and retains the minimal boilerplate needed to write with non-ASCII characters when adding individual Markdown pages to your site.
If your Markdown pages use the `layout` frontmatter property, then HTML encoding will be handled by the designated layout component instead, and the `<meta charset="utf-8">` tag will not be added to your page by default.
If you require `charset=utf-8` to render your page correctly, make sure that your layout components contain the `<meta charset="utf-8">` tag. You may need to add this if you have not already done so.

View file

@ -1,8 +0,0 @@
---
'@astrojs/markdoc': patch
'@astrojs/mdx': patch
'@astrojs/markdown-remark': patch
'astro': patch
---
Parses frontmatter ourselves

Some files were not shown because too many files have changed in this diff Show more