Skip to content

fix(deps): update astro monorepo (major)

Housekeeper (bot) requested to merge renovate/major-astro-monorepo into master

This MR contains the following updates:

Package Type Update Change
@astrojs/mdx (source) dependencies major ^2.1.1 -> ^4.0.0
astro (source) dependencies major ^4.4.1 -> ^5.0.0

Release Notes

withastro/astro (@​astrojs/mdx)

v4.0.3

Compare Source

Patch Changes

v4.0.2

Compare Source

Patch Changes

v4.0.1

Compare Source

Patch Changes

v4.0.0

Compare Source

Major Changes

  • #​12231 90ae100 Thanks @​bluwy! - 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.

  • #​12008 5608338 Thanks @​Princesseuh! - 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.

Minor Changes

  • #​12539 827093e Thanks @​bluwy! - Drops node 21 support

  • #​11741 6617491 Thanks @​bluwy! - 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.

Patch Changes

v3.1.9

Compare Source

Patch Changes

v3.1.8

Compare Source

Patch Changes

v3.1.7

Compare Source

Patch Changes

v3.1.6

Compare Source

Patch Changes

v3.1.5

Compare Source

Patch Changes
  • #​11818 88ef1d0 Thanks @​bluwy! - Fixes CSS in the layout component to be ordered first before any other components in the MDX file

v3.1.4

Compare Source

Patch Changes

v3.1.3

Compare Source

Patch Changes

v3.1.2

Compare Source

Patch Changes

v3.1.1

Compare Source

Patch Changes

v3.1.0

Compare Source

Minor Changes

  • #​11144 803dd80 Thanks @​ematipico! - The integration now exposes a function called getContainerRenderer, that can be used inside the Container APIs to load the relative renderer.

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import ReactWrapper from '../src/components/ReactWrapper.astro';
import { loadRenderers } from 'astro:container';
import { getContainerRenderer } from '@&#8203;astrojs/react';

test('ReactWrapper with react renderer', async () => {
  const renderers = await loadRenderers([getContainerRenderer()]);
  const container = await AstroContainer.create({
    renderers,
  });
  const result = await container.renderToString(ReactWrapper);

  expect(result).toContain('Counter');
  expect(result).toContain('Count: <!-- -->5');
});

v3.0.1

Compare Source

Patch Changes

v3.0.0

Compare Source

Major Changes

  • #​10935 ddd8e49 Thanks @​bluwy! - Refactors the MDX transformation to rely only on the unified pipeline. Babel and esbuild transformations are removed, which should result in faster build times. The refactor requires using Astro v4.8.0 but no other changes are necessary.

  • #​10935 ddd8e49 Thanks @​bluwy! - Allows integrations after the MDX integration to update markdown.remarkPlugins and markdown.rehypePlugins, and have the plugins work in MDX too.

    If your integration relies on Astro's previous behavior that prevents integrations from adding remark/rehype plugins for MDX, you will now need to configure @astrojs/mdx with extendMarkdownConfig: false and explicitly specify any remarkPlugins and rehypePlugins options instead.

  • #​10935 ddd8e49 Thanks @​bluwy! - Renames the optimize.customComponentNames option to optimize.ignoreElementNames to better reflect its usecase. Its behaviour is not changed and should continue to work as before.

  • #​10935 ddd8e49 Thanks @​bluwy! - Replaces the internal remark-images-to-component plugin with rehype-images-to-component to let users use additional rehype plugins for images

Patch Changes

  • #​10935 ddd8e49 Thanks @​bluwy! - Simplifies plain MDX components as hast element nodes to further improve HTML string inlining for the optimize option

  • #​10935 ddd8e49 Thanks @​bluwy! - Allows Vite plugins to transform .mdx files before the MDX plugin transforms it

  • #​10935 ddd8e49 Thanks @​bluwy! - Updates the optimize option to group static sibling nodes as a <Fragment />. This reduces the number of AST nodes and simplifies runtime rendering of MDX pages.

  • #​10935 ddd8e49 Thanks @​bluwy! - Tags the MDX component export for quicker component checks while rendering

  • #​10935 ddd8e49 Thanks @​bluwy! - Fixes export const components keys detection for the optimize option

  • #​10935 ddd8e49 Thanks @​bluwy! - Improves optimize handling for MDX components with attributes and inline MDX components

v2.3.1

Compare Source

Patch Changes

  • #​10754 3e7a12c8532411e580fcfdb8445cad8fc8499291 Thanks @​rishi-raj-jain! - Fixes an issue where images in MDX required a relative specifier (e.g. ./)

    Now, you can use the standard ![](img.png) syntax in MDX files for images colocated in the same folder: no relative specifier required!

    There is no need to update your project; your existing images will still continue to work. However, you may wish to remove any relative specifiers from these MDX images as they are no longer necessary:

    - ![A cute dog](./dog.jpg)
+ ![A cute dog](dog.jpg)
<!-- This dog lives in the same folder as my article! -->

  • #​10770 88ee63a3ba4488c60348cb821034e6d4a057efd0 Thanks @​bluwy! - Removes internal MDX processor on buildEnd to free up memory

v2.3.0

Compare Source

Minor Changes
Patch Changes

v2.2.4

Compare Source

Patch Changes

v2.2.3

Compare Source

Patch Changes

v2.2.2

Compare Source

Patch Changes

v2.2.1

Compare Source

Patch Changes

v2.2.0

Compare Source

Minor Changes

  • #​10104 a31bbd7ff8f3ec62ee507f72d1d25140b82ffc18 Thanks @​remcohaszing! - Changes Astro's internal syntax highlighting to use rehype plugins instead of remark plugins. This provides better interoperability with other rehype plugins that deal with code blocks, in particular with third party syntax highlighting plugins and rehype-mermaid.

    This may be a breaking change if you are currently using:

    • a remark plugin that relies on nodes of type html
    • a rehype plugin that depends on nodes of type raw.

    Please review your rendered code samples carefully, and if necessary, consider using a rehype plugin that deals with the generated element nodes instead. You can transform the AST of raw HTML strings, or alternatively use hast-util-to-html to get a string from a raw node.

Patch Changes
withastro/astro (astro)

v5.1.1

Compare Source

Patch Changes

v5.1.0

Compare Source

Minor Changes

  • #​12441 b4fec3c Thanks @​ascorbic! - Adds experimental session support

    Sessions are used to store user state between requests for server-rendered pages, such as login status, shopping cart contents, or other user-specific data.

v5.0.9

Compare Source

Patch Changes

v5.0.8

Compare Source

Patch Changes

v5.0.7

Compare Source

Patch Changes

v5.0.6

Compare Source

Patch Changes

v5.0.5

Compare Source

Patch Changes

v5.0.4

Compare Source

Patch Changes

v5.0.3

Compare Source

Patch Changes

  • #​12645 8704c54 Thanks @​sarah11918! - Updates some reference links in error messages for new v5 docs.

  • #​12641 48ca399 Thanks @​ascorbic! - Fixes a bug where astro info --copy wasn't working correctly on macOS systems.

  • #​12461 62939ad Thanks @​kyr0! - Removes the misleading log message telling that a custom renderer is not recognized while it clearly is and works.

  • #​12642 ff18b9c Thanks @​ematipico! - Provides more information when logging a warning for accessing Astro.request.headers in prerendered pages

  • #​12634 03958d9 Thanks @​delucis! - Improves error message formatting for user config and content collection frontmatter

  • #​12547 6b6e18d Thanks @​mtwilliams-code! - Fixes a bug where URL search parameters weren't passed when using the i18n fallback feature.

  • #​12449 e6b8017 Thanks @​apatel369! - Fixes an issue where the custom assetFileNames configuration caused assets to be incorrectly moved to the server directory instead of the client directory, resulting in 404 errors when accessed from the client side.

  • #​12518 e216250 Thanks @​ematipico! - Fixes an issue where SSR error pages would return duplicated custom headers.

  • #​12625 74bfad0 Thanks @​ematipico! - Fixes an issue where the experimental.svg had incorrect type, resulting in some errors in the editors.

  • #​12631 dec0305 Thanks @​ascorbic! - Fixes a bug where the class attribute was rendered twice on the image component

  • #​12623 0e4fecb Thanks @​ascorbic! - Correctly handles images in content collections with uppercase file extensions

  • #​12633 8a551c1 Thanks @​bluwy! - Cleans up content layer sync during builds and programmatic sync() calls

  • #​12640 22e405a Thanks @​ascorbic! - Fixes a bug that caused content collections to be returned empty when run in a test environment

  • #​12613 306c9f9 Thanks @​matthewp! - Fix use of cloned requests in middleware with clientAddress

    When using context.clientAddress or Astro.clientAddress Astro looks up the address in a hidden property. Cloning a request can cause this hidden property to be lost.

    The fix is to pass the address as an internal property instead, decoupling it from the request.

v5.0.2

Compare Source

Patch Changes

v5.0.1

Compare Source

Patch Changes

v5.0.0

Compare Source

Major Changes

  • #​11798 e9e2139 Thanks @​matthewp! - 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.

  • #​11864 ee38b3a Thanks @​ematipico! - ### [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.

-import type {RouteData} from 'astro';
+import type {IntegrationRouteData} from "astro"

-function useRoute(route: RouteData) {
+function useRoute(route: IntegrationRouteData) {

}

  • #​12524 9f44019 Thanks @​bluwy! - Bumps Vite to ^6.0.1 and handles its breaking changes

  • #​10742 b6fbdaa Thanks @​ematipico! - The lowest version of Node supported by Astro is now Node v18.17.1 and higher.

  • #​11916 46ea29f Thanks @​bluwy! - 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.

  • #​11982 d84e444 Thanks @​Princesseuh! - 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.

  • #​11861 3ab3b4e Thanks @​bluwy! - 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.

  • #​11987 bf90a53 Thanks @​florian-lefebvre! - 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:

    ctx.locals = {
  one: 1,
  two: 2,
};

    This can be changed to an assignment on the existing object instead:

    Object.assign(ctx.locals, {
  one: 1,
  two: 2,
});

  • #​11908 518433e Thanks @​Princesseuh! - 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.

    import { defineConfig } from 'astro/config';

defineConfig({
  image: {
    endpoint: {
      route: '/image',
      entrypoint: './src/image_endpoint.ts',
    },
  },
});

  • #​12008 5608338 Thanks @​Princesseuh! - 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.

  • #​11679 ea71b90 Thanks @​florian-lefebvre! - The astro:env feature introduced behind a flag in v4.10.0 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.

    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:

v4.16.18

Compare Source

Patch Changes

v4.16.17

Compare Source

Patch Changes

v4.16.16

Compare Source

Patch Changes

v4.16.15

Compare Source

Patch Changes

v4.16.14

Compare Source

Patch Changes

v4.16.13

Compare Source

Patch Changes

  • #​12436 453ec6b Thanks @​martrapp! - Fixes a potential null access in the clientside router

  • #​12392 0462219 Thanks @​apatel369! - Fixes an issue where scripts were not correctly injected during the build. The issue was triggered when there were injected routes with the same entrypoint and different pattern

v4.16.12

Compare Source

Patch Changes
  • #​12420 acac0af Thanks @​ematipico! - Fixes an issue where the dev server returns a 404 status code when a user middleware returns a valid Response.

v4.16.11

Compare Source

Patch Changes

v4.16.10

Compare Source

Patch Changes

v4.16.9

Compare Source

Patch Changes

v4.16.8

Compare Source

Patch Changes

v4.16.7

Compare Source

Patch Changes

v4.16.6

Compare Source

Patch Changes

  • #​11823 a3d30a6 Thanks @​DerTimonius! - fix: improve error message when inferSize is used in local images with the Image component

  • #​12227 8b1a641 Thanks @​florian-lefebvre! - Fixes a case where environment variables would not be refreshed when using astro:env

  • #​12239 2b6daa5 Thanks @​ematipico! - BREAKING CHANGE to the experimental Container API only

    Changes the default page rendering behavior of Astro components in containers, and adds a new option partial: false to render full Astro pages as before.

    Previously, the Container API was rendering all Astro components as if they were full Astro pages containing <!DOCTYPE html> by default. This was not intended, and now by default, all components will render as page partials: only the contents of the components without a page shell.

    To render the component as a full-fledged Astro page, pass a new option called partial: false to renderToString() and renderToResponse():

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import Card from '../src/components/Card.astro';

const container = AstroContainer.create();

await container.renderToString(Card); // the string will not contain `<!DOCTYPE html>`
await container.renderToString(Card, { partial: false }); // the string will contain `<!DOCTYPE html>`

v4.16.5

Compare Source

Patch Changes

v4.16.4

Compare Source

Patch Changes

  • #​12223 79ffa5d Thanks @​ArmandPhilippot! - Fixes a false positive reported by the dev toolbar Audit app where a label was considered missing when associated with a button

    The button element can be used with a label (e.g. to create a switch) and should not be reported as an accessibility issue when used as a child of a label.

  • #​12199 c351352 Thanks @​ematipico! - Fixes a regression in the computation of Astro.currentLocale

  • #​12222 fb55695 Thanks @​ematipico! - Fixes an issue where the edge middleware couldn't correctly compute the client IP address when calling ctx.clientAddress()

v4.16.3

Compare Source

Patch Changes

v4.16.2

Compare Source

Patch Changes

v4.16.1

Compare Source

Patch Changes

v4.16.0

Compare Source

Minor Changes

  • #​12039 710a1a1 Thanks @​ematipico! - Adds a markdown.shikiConfig.langAlias option that allows aliasing a non-supported code language to a known language. This is useful when the language of your code samples is not a built-in Shiki language, but you want your Markdown source to contain an accurate language while also displaying syntax highlighting.

    The following example configures Shiki to highlight cjs code blocks using the javascript syntax highlighter:

    import { defineConfig } from 'astro/config';

export default defineConfig({
  markdown: {
    shikiConfig: {
      langAlias: {
        cjs: 'javascript',
      },
    },
  },
});

    Then in your Markdown, you can use the alias as the language for a code block for syntax highlighting:

    ```cjs
'use strict';

function commonJs() {
  return 'I am a commonjs file';
}
```

  • #​11984 3ac2263 Thanks @​chaegumi! - Adds a new build.concurreny configuration option to specify the number of pages to build in parallel

    In most cases, you should not change the default value of 1.

    Use this option only when other attempts to reduce the overall rendering time (e.g. batch or cache long running tasks like fetch calls or data access) are not possible or are insufficient.

    Use this option only if the refactors are not possible. If the number is set too high, the page rendering may slow down due to insufficient memory resources and because JS is single-threaded.

    [!WARNING] This feature is stable and is not considered experimental. However, this feature is only intended to address difficult performance issues, and breaking changes may occur in a minor release to keep this option as performant as possible.

    // astro.config.mjs
import { defineConfig } from 'astro';

export default defineConfig({
  build: {
    concurrency: 2,
  },
});
Patch Changes

  • #​12160 c6fd1df Thanks @​louisescher! - Fixes a bug where astro.config.mts and astro.config.cts weren't reloading the dev server upon modifications.

  • #​12130 e96bcae Thanks @​thehansys! - Fixes a bug in the parsing of x-forwarded-\* Request headers, where multiple values assigned to those headers were not correctly parsed.

    Now, headers like x-forwarded-proto: https,http are correctly parsed.

  • #​12147 9db755a Thanks @​ascorbic! - Skips setting statusMessage header for HTTP/2 response

    HTTP/2 doesn't support status message, so setting this was logging a warning.

  • #​12151 bb6d37f Thanks @​ematipico! - Fixes an issue where Astro.currentLocale wasn't incorrectly computed when the defaultLocale belonged to a custom locale path.

  • Updated dependencies [710a1a1]:

v4.15.12

Compare Source

Patch Changes

v4.15.11

Compare Source

Patch Changes

  • #​12097 11d447f Thanks @​ascorbic! - Fixes error where references in content layer schemas sometimes incorrectly report as missing

  • #​12108 918953b Thanks @​lameuler! - Fixes a bug where data URL images were not correctly handled. The bug resulted in an ENAMETOOLONG error.

  • #​12105 42037f3 Thanks @​ascorbic! - Returns custom statusText that has been set in a Response

  • #​12109 ea22558 Thanks @​ematipico! - Fixes a regression that was introduced by an internal refactor of how the middleware is loaded by the Astro application. The regression was introduced by #​11550.

    When the edge middleware feature is opted in, Astro removes the middleware function from the SSR manifest, and this wasn't taken into account during the refactor.

  • #​12106 d3a74da Thanks @​ascorbic! - Handles case where an immutable Response object is returned from an endpoint

  • #​12090 d49a537 Thanks @​markjaquith! - Server islands: changes the server island HTML placeholder comment so that it is much less likely to get removed by HTML minifiers.

v4.15.10

Compare Source

Patch Changes

v4.15.9

Compare Source

Patch Changes

  • #​12034 5b3ddfa Thanks @​ematipico! - Fixes an issue where the middleware wasn't called when a project uses 404.astro.

  • #​12042 243ecb6 Thanks @​ematipico! - Fixes a problem in the Container API, where a polyfill wasn't correctly applied. This caused an issue in some environments where crypto isn't supported.

  • #​12038 26ea5e8 Thanks @​ascorbic! - 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.

v4.15.8

Compare Source

Patch Changes

v4.15.7

Compare Source

Patch Changes

v4.15.6

Compare Source

Patch Changes

v4.15.5

Compare Source

Patch Changes

  • #​11939 7b09c62 Thanks @​bholmesdev! - Adds support for Zod discriminated unions on Action form inputs. This allows forms with different inputs to be submitted to the same action, using a given input to decide which object should be used for validation.

    This example accepts either a create or update form submission, and uses the type field to determine which object to validate against.

    import { defineAction } from 'astro:actions';
import { z } from 'astro:schema';

export const server = {
  changeUser: defineAction({
    accept: 'form',
    input: z.discriminatedUnion('type', [
      z.object({
        type: z.literal('create'),
        name: z.string(),
        email: z.string().email(),
      }),
      z.object({
        type: z.literal('update'),
        id: z.number(),
        name: z.string(),
        email: z.string().email(),
      }),
    ]),
    async handler(input) {
      if (input.type === 'create') {
        // input is { type: 'create', name: string, email: string }
      } else {
        // input is { type: 'update', id: number, name: string, email: string }
      }
    },
  }),
};

    The corresponding create and update forms may look like this:

v4.15.4

Compare Source

Patch Changes

  • #​11879 bd1d4aa Thanks @​matthewp! - Allow passing a cryptography key via ASTRO_KEY

    For Server islands Astro creates a cryptography key in order to hash props for the islands, preventing accidental leakage of secrets.

    If you deploy to an environment with rolling updates then there could be multiple instances of your app with different keys, causing potential key mismatches.

    To fix this you can now pass the ASTRO_KEY environment variable to your build in order to reuse the same key.

    To generate a key use:

    astro create-key

    This will print out an environment variable to set like:

    ASTRO_KEY=PIAuyPNn2aKU/bviapEuc/nVzdzZPizKNo3OqF/5PmQ=

  • #​11935 c58193a Thanks @​Princesseuh! - Fixes astro add not using the proper export point when adding certain adapters

v4.15.3

Compare Source

Patch Changes

v4.15.2

Compare Source

Patch Changes

v4.15.1

Compare Source

Patch Changes

v4.15.0

Compare Source

Minor Changes

  • #​11729 1c54e63 Thanks @​ematipico! - Adds a new variant sync for the astro:config:setup hook's command property. This value is set when calling the command astro sync.

    If your integration previously relied on knowing how many variants existed for the command property, you must update your logic to account for this new option.

  • #​11743 cce0894 Thanks @​ph1p! - Adds a new, optional property timeout for the client:idle directive.

    This value allows you to specify a maximum time to wait, in milliseconds, before hydrating a UI framework component, even if the page is not yet done with its initial load. This means you can delay hydration for lower-priority UI elements with more control to ensure your element is interactive within a specified time frame.

    <ShowHideButton client:idle={{ timeout: 500 }} />

  • #​11677 cb356a5 Thanks @​ematipico! - Adds a new option fallbackType to i18n.routing configuration that allows you to control how fallback pages are handled.

    When i18n.fallback is configured, this new routing option controls whether to redirect to the fallback page, or to rewrite the fallback page's content in place.

    The "redirect" option is the default value and matches the current behavior of the existing fallback system.

    The option "rewrite" uses the new rewriting system to create fallback pages that render content on the original, requested URL without a browser refresh.

    For example, the following configuration will generate a page /fr/index.html that will contain the same HTML rendered by the page /en/index.html when src/pages/fr/index.astro does not exist.

    // astro.config.mjs
export default defineConfig({
  i18n: {
    locals: ['en', 'fr'],
    defaultLocale: 'en',
    routing: {
      prefixDefaultLocale: true,
      fallbackType: 'rewrite',
    },
    fallback: {
      fr: 'en',
    },
  },
});

  • #​11708 62b0d20 Thanks @​martrapp! - Adds a new object swapFunctions to expose the necessary utility functions on astro:transitions/client that allow you to build custom swap functions to be used with view transitions.

    The example below uses these functions to replace Astro's built-in default swap function with one that only swaps the <main> part of the page:

    <script>
  import { swapFunctions } from 'astro:transitions/client';

  document.addEventListener('astro:before-swap', (e) => { e.swap = () => swapMainOnly(e.newDocument) });

  function swapMainOnly(doc: Document) {
    swapFunctions.deselectScripts(doc);
    swapFunctions.swapRootAttributes(doc);
    swapFunctions.swapHeadElements(doc);
    const restoreFocusFunction = swapFunctions.saveFocus();
    const newMain = doc.querySelector('main');
    const oldMain = document.querySelector('main');
    if (newMain && oldMain) {
      swapFunctions.swapBodyElement(newMain, oldMain);
    } else {
      swapFunctions.swapBodyElement(doc.body, document.body);
    }
    restoreFocusFunction();
  };
</script>

    See the view transitions guide for more information about hooking into the astro:before-swap lifecycle event and adding a custom swap implementation.

  • #​11843 5b4070e Thanks @​bholmesdev! - Exposes z from the new astro:schema module. This is the new recommended import source for all Zod utilities when using Astro Actions.

v4.14.6

Compare Source

Patch Changes

v4.14.5

Compare Source

Patch Changes

v4.14.4

Compare Source

Patch Changes

  • #​11794 3691a62 Thanks @​bholmesdev! - Fixes unexpected warning log when using Actions on "hybrid" rendered projects.

  • #​11801 9f943c1 Thanks @​delucis! - Fixes a bug where the filePath property was not available on content collection entries when using the content layer file() loader with a JSON file that contained an object instead of an array. This was breaking use of the image() schema utility among other things.

v4.14.3

Compare Source

Patch Changes

v4.14.2

Compare Source

Patch Changes

v4.14.1

Compare Source

Patch Changes

  • #​11725 6c1560f Thanks @​ascorbic! - Prevents content layer importing node builtins in runtime

  • #​11692 35af73a Thanks @​matthewp! - Prevent errant HTML from crashing server islands

    When an HTML minifier strips away the server island comment, the script can't correctly know where the end of the fallback content is. This makes it so that it simply doesn't remove any DOM in that scenario. This means the fallback isn't removed, but it also doesn't crash the browser.

  • #​11727 3c2f93b Thanks @​florian-lefebvre! - Fixes a type issue when using the Content Layer in dev

v4.14.0

Compare Source

Minor Changes

  • #​11657 a23c69d Thanks @​bluwy! - Deprecates the option for route-generating files to export a dynamic value for prerender. Only static values are now supported (e.g. export const prerender = true or = false). This allows for better treeshaking and bundling configuration in the future.

    Adds a new "astro:route:setup" hook to the Integrations API to allow you to dynamically set options for a route at build or request time through an integration, such as enabling on-demand server rendering.

    To migrate from a dynamic export to the new hook, update or remove any dynamic prerender exports from individual routing files:

    // src/pages/blog/[slug].astro
- export const prerender = import.meta.env.PRERENDER

    Instead, create an integration with the "astro:route:setup" hook and update the route's prerender option:

    // astro.config.mjs
import { defineConfig } from 'astro/config';
import { loadEnv } from 'vite';

export default defineConfig({
  integrations: [setPrerender()],
});

function setPrerender() {
  const { PRERENDER } = loadEnv(process.env.NODE_ENV, process.cwd(), '');

  return {
    name: 'set-prerender',
    hooks: {
      'astro:route:setup': ({ route }) => {
        if (route.component.endsWith('/blog/[slug].astro')) {
          route.prerender = PRERENDER;
        }
      },
    },
  };
}

  • #​11360 a79a8b0 Thanks @​ascorbic! - Adds a new injectTypes() utility to the Integration API and refactors how type generation works

    Use injectTypes() in the astro:config:done hook to inject types into your user's project by adding a new a *.d.ts file.

    The filename property will be used to generate a file at /.astro/integrations/<normalized_integration_name>/<normalized_filename>.d.ts and must end with ".d.ts".

    The content property will create the body of the file, and must be valid TypeScript.

    Additionally, injectTypes() returns a URL to the normalized path so you can overwrite its content later on, or manipulate it in any way you want.

    // my-integration/index.js
export default {
  name: 'my-integration',
  'astro:config:done': ({ injectTypes }) => {
    injectTypes({
      filename: 'types.d.ts',
      content: "declare module 'virtual:my-integration' {}",
    });
  },
};

    Codegen has been refactored. Although src/env.d.ts will continue to work as is, we recommend you update it:

    - /// <reference types="astro/client" />
+ /// <reference path="../.astro/types.d.ts" />
- /// <reference path="../.astro/env.d.ts" />
- /// <reference path="../.astro/actions.d.ts" />

  • #​11605 d3d99fb Thanks @​jcayzac! - Adds a new property meta to Astro's built-in <Code /> component.

    This allows you to provide a value for Shiki's meta attribute to pass options to transformers.

    The following example passes an option to highlight lines 1 and 3 to Shiki's tranformerMetaHighlight:

v4.13.4

Compare Source

Patch Changes

v4.13.3

Compare Source

Patch Changes

  • #​11653 32be549 Thanks @​florian-lefebvre! - Updates astro:env docs to reflect current developments and usage guidance

  • #​11658 13b912a Thanks @​bholmesdev! - Fixes orThrow() type when calling an Action without an input validator.

  • #​11603 f31d466 Thanks @​bholmesdev! - Improves user experience when render an Action result from a form POST request:

    • Removes "Confirm post resubmission?" dialog when refreshing a result.
    • Removes the ?_astroAction=NAME flag when a result is rendered.

    Also improves the DX of directing to a new route on success. Actions will now redirect to the route specified in your action string on success, and redirect back to the previous page on error. This follows the routing convention of established backend frameworks like Laravel.

    For example, say you want to redirect to a /success route when actions.signup succeeds. You can add /success to your action string like so:

    <form method="POST" action={'/success' + actions.signup}></form>
    • On success, Astro will redirect to /success.
    • On error, Astro will redirect back to the current page.

    You can retrieve the action result from either page using the Astro.getActionResult() function.

Note on security

This uses a temporary cookie to forward the action result to the next page. The cookie will be deleted when that page is rendered.

⚠ The action result is not encrypted. In general, we recommend returning minimal data from an action handler to a) avoid leaking sensitive information, and b) avoid unexpected render issues once the temporary cookie is deleted. For example, a login function may return a user's session id to retrieve from your Astro frontmatter, rather than the entire user object.

v4.13.2

Compare Source

Patch Changes

v4.13.1

Compare Source

Patch Changes

  • #​11584 a65ffe3 Thanks @​bholmesdev! - Removes async local storage dependency from Astro Actions. This allows Actions to run in Cloudflare and Stackblitz without opt-in flags or other configuration.

    This also introduces a new convention for calling actions from server code. Instead of calling actions directly, you must wrap function calls with the new Astro.callAction() utility.

    callAction() is meant to trigger an action from server code. getActionResult() usage with form submissions remains unchanged.

v4.13.0

Compare Source

Minor Changes

  • #​11507 a62345f Thanks @​ematipico! - Adds color-coding to the console output during the build to highlight slow pages.

    Pages that take more than 500 milliseconds to render will have their build time logged in red. This change can help you discover pages of your site that are not performant and may need attention.

  • #​11379 e5e2d3e Thanks @​alexanderniebuhr! - The experimental.contentCollectionJsonSchema feature introduced behind a flag in v4.5.0 is no longer experimental and is available for general use.

    If you are working with collections of type data, Astro will now auto-generate JSON schema files for your editor to get IntelliSense and type-checking. A separate file will be created for each data collection in your project based on your collections defined in src/content/config.ts using a library called zod-to-json-schema.

    This feature requires you to manually set your schema's file path as the value for $schema in each data entry file of the collection:

    {
  "$schema": "../../../.astro/collections/authors.schema.json",
  "name": "Armand",
  "skills": ["Astro", "Starlight"]
}

    Alternatively, you can set this value in your editor settings. For example, to set this value in VSCode's json.schemas setting, provide the path of files to match and the location of your JSON schema:

    {
  "json.schemas": [
    {
      "fileMatch": ["/src/content/authors/**"],
      "url": "./.astro/collections/authors.schema.json"
    }
  ]
}

    If you were previously using this feature, please remove the experimental flag from your Astro config:

    import { defineConfig } from 'astro'

export default defineConfig({
-  experimental: {
-    contentCollectionJsonSchema: true
-  }
})

    If you have been waiting for stabilization before using JSON Schema generation for content collections, you can now do so.

    Please see the content collections guide for more about this feature.

  • #​11542 45ad326 Thanks @​ematipico! - The experimental.rewriting feature introduced behind a flag in v4.8.0 is no longer experimental and is available for general use.

    Astro.rewrite() and context.rewrite() allow you to render a different page without changing the URL in the browser. Unlike using a redirect, your visitor is kept on the original page they visited.

    Rewrites can be useful for showing the same content at multiple paths (e.g. /products/shoes/men/ and /products/men/shoes/) without needing to maintain two identical source files.

    Rewrites are supported in Astro pages, endpoints, and middleware.

    Return Astro.rewrite() in the frontmatter of a .astro page component to display a different page's content, such as fallback localized content:

v4.12.3

Compare Source

Patch Changes

  • #​11509 dfbca06 Thanks @​bluwy! - Excludes hoisted scripts and styles from Astro components imported with ?url or ?raw

  • #​11561 904f1e5 Thanks @​ArmandPhilippot! - Uses the correct pageSize default in page.size JSDoc comment

  • #​11571 1c3265a Thanks @​bholmesdev! - BREAKING CHANGE to the experimental Actions API only. Install the latest @astrojs/react integration as well if you're using React 19 features.

    Make .safe() the default return value for actions. This means { data, error } will be returned when calling an action directly. If you prefer to get the data while allowing errors to throw, chain the .orThrow() modifier.

    import { actions } from 'astro:actions';

// Before
const { data, error } = await actions.like.safe();
// After
const { data, error } = await actions.like();

// Before
const newLikes = await actions.like();
// After
const newLikes = await actions.like.orThrow();

v4.12.2

Compare Source

Patch Changes

  • #​11505 8ff7658 Thanks @​ematipico! - Enhances the dev server logging when rewrites occur during the lifecycle or rendering.

    The dev server will log the status code before and after a rewrite:

    08:16:48 [404] (rewrite) /foo/about 200ms
08:22:13 [200] (rewrite) /about 23ms

  • #​11506 026e8ba Thanks @​sarah11918! - Fixes typo in documenting the slot="fallback" attribute for Server Islands experimental feature.

  • #​11508 ca335e1 Thanks @​cramforce! - Escapes HTML in serialized props

  • #​11501 4db78ae Thanks @​martrapp! - Adds the missing export for accessing the getFallback() function of the client site router.

v4.12.1

Compare Source

Patch Changes

  • #​11486 9c0c849 Thanks @​ematipico! - Adds a new function called addClientRenderer to the Container API.

    This function should be used when rendering components using the client:* directives. The addClientRenderer API must be used after the use of the addServerRenderer:

    const container = await experimental_AstroContainer.create();
container.addServerRenderer({ renderer });
container.addClientRenderer({ name: '@&#8203;astrojs/react', entrypoint: '@&#8203;astrojs/react/client.js' });
const response = await container.renderToResponse(Component);

  • #​11500 4e142d3 Thanks @​Princesseuh! - Fixes inferRemoteSize type not working

  • #​11496 53ccd20 Thanks @​alfawal! - Hide the dev toolbar on window.print() (CTRL + P)

v4.12.0

Compare Source

Minor Changes

  • #​11341 49b5145 Thanks @​madcampos! - Adds support for Shiki's defaultColor option.

    This option allows you to override the values of a theme's inline style, adding only CSS variables to give you more flexibility in applying multiple color themes.

    Configure defaultColor: false in your Shiki config to apply throughout your site, or pass to Astro's built-in <Code> component to style an individual code block.

    import { defineConfig } from 'astro/config';
export default defineConfig({
  markdown: {
    shikiConfig: {
      themes: {
        light: 'github-light',
        dark: 'github-dark',
      },
      defaultColor: false,
    },
  },
});

v4.11.6

Compare Source

Patch Changes

  • #​11459 bc2e74d Thanks @​mingjunlu! - Fixes false positive audit warnings on elements with the role "tabpanel".

  • #​11472 cb4e6d0 Thanks @​delucis! - Avoids targeting all files in the src/ directory for eager optimization by Vite. After this change, only JSX, Vue, Svelte, and Astro components get scanned for early optimization.

  • #​11387 b498461 Thanks @​bluwy! - Fixes prerendering not removing unused dynamic imported chunks

  • #​11437 6ccb30e Thanks @​NuroDev! - Fixes a case where Astro's config experimental.env.schema keys did not allow numbers. Numbers are still not allowed as the first character to be able to generate valid JavaScript identifiers

  • #​11439 08baf56 Thanks @​bholmesdev! - Expands the isInputError() utility from astro:actions to accept errors of any type. This should now allow type narrowing from a try / catch block.

    // example.ts
import { actions, isInputError } from 'astro:actions';

try {
  await actions.like(new FormData());
} catch (error) {
  if (isInputError(error)) {
    console.log(error.fields);
  }
}

  • #​11452 0e66849 Thanks @​FugiTech! - Fixes an issue where using .nullish() in a formdata Astro action would always parse as a string

  • #​11438 619f07d Thanks @​bholmesdev! - Exposes utility types from astro:actions for the defineAction handler (ActionHandler) and the ActionError code (ActionErrorCode).

  • #​11456 17e048d Thanks @​RickyC0626! - Fixes astro dev --open unexpected behavior that spawns a new tab every time a config file is saved

  • #​11337 0a4b31f Thanks @​florian-lefebvre! - Adds a new property experimental.env.validateSecrets to allow validating private variables on the server.

    By default, this is set to false and only public variables are checked on start. If enabled, secrets will also be checked on start (dev/build modes). This is useful for example in some CIs to make sure all your secrets are correctly set before deploying.

    // astro.config.mjs
import { defineConfig, envField } from 'astro/config';

export default defineConfig({
  experimental: {
    env: {
      schema: {
        // ...
      },
      validateSecrets: true,
    },
  },
});

  • #​11443 ea4bc04 Thanks @​bholmesdev! - Expose new ActionReturnType utility from astro:actions. This infers the return type of an action by passing typeof actions.name as a type argument. This example defines a like action that returns likes as an object:

    // actions/index.ts
import { defineAction } from 'astro:actions';

export const server = {
  like: defineAction({
    handler: () => {
      /* ... */
      return { likes: 42 };
    },
  }),
};

    In your client code, you can infer this handler return value with ActionReturnType:

    // client.ts
import { actions, ActionReturnType } from 'astro:actions';

type LikesResult = ActionReturnType<typeof actions.like>;
// -> { likes: number }

  • #​11436 7dca68f Thanks @​bholmesdev! - Fixes astro:actions autocompletion for the defineAction accept property

  • #​11455 645e128 Thanks @​florian-lefebvre! - Improves astro:env invalid variables errors

v4.11.5

Compare Source

Patch Changes

v4.11.4

Compare Source

Patch Changes

v4.11.3

Compare Source

Patch Changes

v4.11.2

Compare Source

Patch Changes

  • #​11335 4c4741b Thanks @​ematipico! - Reverts #​11292, which caused a regression to the input type

  • #​11326 41121fb Thanks @​florian-lefebvre! - Fixes a case where running astro sync when using the experimental astro:env feature would fail if environment variables were missing

  • #​11338 9752a0b Thanks @​zaaakher! - Fixes svg icon margin in devtool tooltip title to look coherent in rtl and ltr layouts

  • #​11331 f1b78a4 Thanks @​bluwy! - Removes resolve package and simplify internal resolve check

  • #​11339 8fdbf0e Thanks @​matthewp! - Remove non-fatal errors from telemetry

    Previously we tracked non-fatal errors in telemetry to get a good idea of the types of errors that occur in astro dev. However this has become noisy over time and results in a lot of data that isn't particularly useful. This removes those non-fatal errors from being tracked.

v4.11.1

Compare Source

Patch Changes

v4.11.0

Compare Source

Minor Changes

  • #​11197 4b46bd9 Thanks @​braebo! - Adds ShikiTransformer support to the <Code /> component with a new transformers prop.

    Note that transformers only applies classes and you must provide your own CSS rules to target the elements of your code block.

v4.10.3

Compare Source

Patch Changes

  • #​11213 94ac7ef Thanks @​florian-lefebvre! - Removes the PUBLIC_ prefix constraint for astro:env public variables

  • #​11213 94ac7ef Thanks @​florian-lefebvre! - BREAKING CHANGE to the experimental astro:env feature only

    Server secrets specified in the schema must now be imported from astro:env/server. Using getSecret() is no longer required to use these environment variables in your schema:

    - import { getSecret } from 'astro:env/server'
- const API_SECRET = getSecret("API_SECRET")
+ import { API_SECRET } from 'astro:env/server'

    Note that using getSecret() with these keys is still possible, but no longer involves any special handling and the raw value will be returned, just like retrieving secrets not specified in your schema.

  • #​11234 4385bf7 Thanks @​ematipico! - Adds a new function called addServerRenderer to the Container API. Use this function to manually store renderers inside the instance of your container.

    This new function should be preferred when using the Container API in environments like on-demand pages:

    import type { APIRoute } from 'astro';
import { experimental_AstroContainer } from 'astro/container';
import reactRenderer from '@&#8203;astrojs/react/server.js';
import vueRenderer from '@&#8203;astrojs/vue/server.js';
import ReactComponent from '../components/button.jsx';
import VueComponent from '../components/button.vue';

// MDX runtime is contained inside the Astro core
import mdxRenderer from 'astro/jsx/server.js';

// In case you need to import a custom renderer
import customRenderer from '../renderers/customRenderer.js';

export const GET: APIRoute = async (ctx) => {
  const container = await experimental_AstroContainer.create();
  container.addServerRenderer({ renderer: reactRenderer });
  container.addServerRenderer({ renderer: vueRenderer });
  container.addServerRenderer({ renderer: customRenderer });
  // You can pass a custom name too
  container.addServerRenderer({
    name: 'customRenderer',
    renderer: customRenderer,
  });
  const vueComponent = await container.renderToString(VueComponent);
  return await container.renderToResponse(Component);
};

  • #​11249 de60c69 Thanks @​markgaze! - Fixes a performance issue with JSON schema generation

  • #​11242 e4fc2a0 Thanks @​ematipico! - Fixes a case where the virtual module astro:container wasn't resolved

  • #​11236 39bc3a5 Thanks @​ascorbic! - Fixes a case where symlinked content collection directories were not correctly resolved

  • #​11258 d996db6 Thanks @​ascorbic! - Adds a new error RewriteWithBodyUsed that throws when Astro.rewrite is used after the request body has already been read.

  • #​11243 ba2b14c Thanks @​V3RON! - Fixes a prerendering issue for libraries in node_modules when a folder with an underscore is in the path.

  • #​11244 d07d2f7 Thanks @​ematipico! - Improves the developer experience of the custom 500.astro page in development mode.

    Before, in development, an error thrown during the rendering phase would display the default error overlay, even when users had the 500.astro page.

    Now, the development server will display the 500.astro and the original error is logged in the console.

  • #​11240 2851b0a Thanks @​ascorbic! - Ignores query strings in module identifiers when matching ".astro" file extensions in Vite plugin

  • #​11245 e22be22 Thanks @​bluwy! - Refactors prerendering chunk handling to correctly remove unused code during the SSR runtime

v4.10.2

Compare Source

Patch Changes

  • #​11231 58d7dbb Thanks @​ematipico! - Fixes a regression for getViteConfig, where the inline config wasn't merged in the final config.

  • #​11228 1e293a1 Thanks @​ascorbic! - Updates getCollection() to always return a cloned array

  • #​11207 7d9aac3 Thanks @​ematipico! - Fixes an issue in the rewriting logic where old data was not purged during the rewrite flow. This caused some false positives when checking the validity of URL path names during the rendering phase.

  • #​11189 75a8fe7 Thanks @​ematipico! - Improve error message when using getLocaleByPath on path that doesn't contain any locales.

  • #​11195 0a6ab6f Thanks @​florian-lefebvre! - Adds support for enums to astro:env

    You can now call envField.enum:

    import { defineConfig, envField } from 'astro/config';

export default defineConfig({
  experimental: {
    env: {
      schema: {
        API_VERSION: envField.enum({
          context: 'server',
          access: 'secret',
          values: ['v1', 'v2'],
        }),
      },
    },
  },
});

  • #​11210 66fc028 Thanks @​matthewp! - Close the iterator only after rendering is complete

  • #​11195 0a6ab6f Thanks @​florian-lefebvre! - Adds additional validation options to astro:env

    astro:env schema datatypes string and number now have new optional validation rules:

    import { defineConfig, envField } from 'astro/config';

export default defineConfig({
  experimental: {
    env: {
      schema: {
        FOO: envField.string({
          // ...
          max: 32,
          min: 3,
          length: 12,
          url: true,
          includes: 'foo',
          startsWith: 'bar',
          endsWith: 'baz',
        }),
        BAR: envField.number({
          // ...
          gt: 2,
          min: 3,
          lt: 10,
          max: 9,
          int: true,
        }),
      },
    },
  },
});

  • #​11211 97724da Thanks @​matthewp! - Let middleware handle the original request URL

  • #​10607 7327c6a Thanks @​frankbits! - Fixes an issue where a leading slash created incorrect conflict resolution between pages generated from static routes and catch-all dynamic routes

v4.10.1

Compare Source

Patch Changes

v4.10.0

Compare Source

Minor Changes

  • #​10974 2668ef9 Thanks @​florian-lefebvre! - Adds experimental support for the astro:env API.

    The astro:env API lets you configure a type-safe schema for your environment variables, and indicate whether they should be available on the server or the client. Import and use your defined variables from the appropriate /client or /server module:

v4.9.3

Compare Source

Patch Changes

  • #​11171 ff8004f Thanks @​Princesseuh! - Guard globalThis.astroAsset usage in proxy code to avoid errors in wonky situations

  • #​11178 1734c49 Thanks @​theoephraim! - Improves isPromise utility to check the presence of then on an object before trying to access it - which can cause undesired side-effects on Proxy objects

  • #​11183 3cfa2ac Thanks @​66Leo66! - Suggest pnpm dlx instead of pnpx in update check.

  • #​11147 2d93902 Thanks @​kitschpatrol! - Fixes invalid MIME types in Picture source elements for jpg and svg extensions, which was preventing otherwise valid source variations from being shown by the browser

  • #​11141 19df89f Thanks @​ematipico! - Fixes an internal error that prevented the AstroContainer to render the Content component.

    You can now write code similar to the following to render content collections:

    const entry = await getEntry(collection, slug);
const { Content } = await entry.render();
const content = await container.renderToString(Content);

  • #​11170 ba20c71 Thanks @​matthewp! - Retain client scripts in content cache

v4.9.2

Compare Source

Patch Changes

  • #​11138 98e0372 Thanks @​ematipico! - You can now pass props when rendering a component using the Container APIs:

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import Card from '../src/components/Card.astro';

const container = await AstroContainer.create();
const result = await container.renderToString(Card, {
  props: {
    someState: true,
  },
});

v4.9.1

Compare Source

Patch Changes

v4.9.0

Compare Source

Minor Changes

  • #​11051 12a1bcc Thanks @​ematipico! - Introduces an experimental Container API to render .astro components in isolation.

    This API introduces three new functions to allow you to create a new container and render an Astro component returning either a string or a Response:

    • create(): creates a new instance of the container.
    • renderToString(): renders a component and return a string.
    • renderToResponse(): renders a component and returns the Response emitted by the rendering phase.

    The first supported use of this new API is to enable unit testing. For example, with vitest, you can create a container to render your component with test data and check the result:

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import { expect, test } from 'vitest';
import Card from '../src/components/Card.astro';

test('Card with slots', async () => {
  const container = await AstroContainer.create();
  const result = await container.renderToString(Card, {
    slots: {
      default: 'Card content',
    },
  });

  expect(result).toContain('This is a card');
  expect(result).toContain('Card content');
});

    For a complete reference, see the Container API docs.

    For a feature overview, and to give feedback on this experimental API, see the Container API roadmap discussion.

  • #​11021 2d4c8fa Thanks @​ematipico! - The CSRF protection feature that was introduced behind a flag in v4.6.0 is no longer experimental and is available for general use.

    To enable the stable version, add the new top-level security option in astro.config.mjs. If you were previously using the experimental version of this feature, also delete the experimental flag:

    export default defineConfig({
-  experimental: {
-    security: {
-      csrfProtection: {
-        origin: true
-      }
-    }
-  },
+  security: {
+    checkOrigin: true
+  }
})

    Enabling this setting performs a check that the "origin" header, automatically passed by all modern browsers, matches the URL sent by each Request.

    This check is executed only for pages rendered on demand, and only for the requests POST, PATCH, DELETE and PUT with one of the following "content-type" headers: 'application/x-www-form-urlencoded', 'multipart/form-data', 'text/plain'.

    If the "origin" header doesn't match the pathname of the request, Astro will return a 403 status code and won't render the page.

    For more information, see the security configuration docs.

  • #​11022 be68ab4 Thanks @​ematipico! - The i18nDomains routing feature introduced behind a flag in v3.4.0 is no longer experimental and is available for general use.

    This routing option allows you to configure different domains for individual locales in entirely server-rendered projects using the @​astrojs/node or @​astrojs/vercel adapter with a site configured.

    If you were using this feature, please remove the experimental flag from your Astro config:

    import { defineConfig } from 'astro'

export default defineConfig({
-  experimental: {
-    i18nDomains: true,
-  }
})

    If you have been waiting for stabilization before using this routing option, you can now do so.

    Please see the internationalization docs for more about this feature.

  • #​11071 8ca7c73 Thanks @​bholmesdev! - Adds two new functions experimental_getActionState() and experimental_withState() to support the React 19 useActionState() hook when using Astro Actions. This introduces progressive enhancement when calling an Action with the withState() utility.

    This example calls a like action that accepts a postId and returns the number of likes. Pass this action to the experimental_withState() function to apply progressive enhancement info, and apply to useActionState() to track the result:

    import { actions } from 'astro:actions';
import { experimental_withState } from '@&#8203;astrojs/react/actions';

export function Like({ postId }: { postId: string }) {
  const [state, action, pending] = useActionState(
    experimental_withState(actions.like),
    0, // initial likes
  );

  return (
    <form action={action}>
      <input type="hidden" name="postId" value={postId} />
      <button disabled={pending}>{state} ❤️</button>
    </form>
  );
}

    You can also access the state stored by useActionState() from your action handler. Call experimental_getActionState() with the API context, and optionally apply a type to the result:

    import { defineAction, z } from 'astro:actions';
import { experimental_getActionState } from '@&#8203;astrojs/react/actions';

export const server = {
  like: defineAction({
    input: z.object({
      postId: z.string(),
    }),
    handler: async ({ postId }, ctx) => {
      const currentLikes = experimental_getActionState<number>(ctx);
      // write to database
      return currentLikes + 1;
    },
  }),
};

  • #​11101 a6916e4 Thanks @​linguofeng! - Updates Astro's code for adapters to use the header x-forwarded-for to initialize the clientAddress.

    To take advantage of the new change, integration authors must upgrade the version of Astro in their adapter peerDependencies to 4.9.0.

  • #​11071 8ca7c73 Thanks @​bholmesdev! - Adds compatibility for Astro Actions in the React 19 beta. Actions can be passed to a form action prop directly, and Astro will automatically add metadata for progressive enhancement.

    import { actions } from 'astro:actions';

function Like() {
  return (
    <form action={actions.like}>
      {/* auto-inserts hidden input for progressive enhancement */}
      <button type="submit">Like</button>
    </form>
  );
}
Patch Changes

  • #​11088 9566fa0 Thanks @​bholmesdev! - Allow actions to be called on the server. This allows you to call actions as utility functions in your Astro frontmatter, endpoints, and server-side UI components.

    Import and call directly from astro:actions as you would for client actions:

v4.8.7

Compare Source

Patch Changes

  • #​11073 f5c8fee Thanks @​matthewp! - Prevent cache content from being left in dist folder

    When contentCollectionsCache is enabled temporary cached content is copied into the outDir for processing. This fixes it so that this content is cleaned out, along with the rest of the temporary build JS.

  • #​11054 f6b171e Thanks @​bholmesdev! - Respect error status when handling Actions with a progressive fallback.

  • #​11092 bfe9c73 Thanks @​duckycoding-dev! - Change slot attribute of IntrinsicAttributes to match the definition of HTMLAttributes's own slot attribute of type string | undefined | null

  • #​10875 b5f95b2 Thanks @​W1M0R! - Fixes a typo in a JSDoc annotation

  • #​11111 a5d79dd Thanks @​bholmesdev! - Fix unexpected headers warning on prerendered routes when using Astro Actions.

  • #​11081 af42e05 Thanks @​V3RON! - Correctly position inspection tooltip in RTL mode

    When RTL mode is turned on, the inspection tooltip tend to overflow the window on the left side. Additional check has been added to prevent that.

v4.8.6

Compare Source

Patch Changes

v4.8.5

Compare Source

Patch Changes

v4.8.4

Compare Source

Patch Changes

  • #​11026 8dfb1a2 Thanks @​bluwy! - Skips rendering script tags if it's inlined and empty when experimental.directRenderScript is enabled

  • #​11043 d0d1710 Thanks @​bholmesdev! - Fixes minor type issues in actions component example

  • #​10999 5f353e3 Thanks @​bluwy! - The prefetch feature is updated to better support different browsers and different cache headers setup, including:

    1. All prefetch strategies will now always try to use <link rel="prefetch"> if supported, or will fall back to fetch().
    2. The prefetch() programmatic API's with option is deprecated in favour of an automatic approach that will also try to use <link rel="prefetch> if supported, or will fall back to fetch().

    This change shouldn't affect most sites and should instead make prefetching more effective.

  • #​11041 6cc3fb9 Thanks @​bholmesdev! - Fixes 500 errors when sending empty params or returning an empty response from an action.

  • #​11028 771d1f7 Thanks @​bholmesdev! - Throw on missing server output when using Astro Actions.

  • #​11029 bd34452 Thanks @​bholmesdev! - Actions: include validation error in thrown error message for debugging.

  • #​11046 086694a Thanks @​HiDeoo! - Fixes getViteConfig() type definition to allow passing an inline Astro configuration as second argument

  • #​11026 8dfb1a2 Thanks @​bluwy! - Fixes CSS handling if imported in a script tag in an Astro file when experimental.directRenderScript is enabled

  • #​11020 2e2d6b7 Thanks @​xsynaptic! - Add type declarations for import.meta.env.ASSETS_PREFIX when defined as an object for handling different file types.

  • #​11030 18e7f33 Thanks @​bholmesdev! - Actions: Fix missing message for custom Action errors.

  • #​10981 ad9227c Thanks @​mo! - Adds deprecated HTML attribute "name" to the list of valid attributes. This attribute has been replaced by the global id attribute in recent versions of HTML.

  • #​11013 4ea38e7 Thanks @​QingXia-Ela! - Prevents unhandledrejection error when checking for latest Astro version

  • #​11034 5f2dd45 Thanks @​arganaphang! - Add popovertargetaction to the attribute that can be passed to the button and input element

v4.8.3

Compare Source

Patch Changes

v4.8.2

Compare Source

Patch Changes

v4.8.1

Compare Source

Patch Changes

  • #​10987 05db5f7 Thanks @​ematipico! - Fix a regression where the flag experimental.rewriting was marked mandatory. Is is now optional.

  • #​10975 6b640b3 Thanks @​bluwy! - Passes the scoped style attribute or class to the <picture> element in the <Picture /> component so scoped styling can be applied to the <picture> element

v4.8.0

Compare Source

Minor Changes

  • #​10935 ddd8e49 Thanks @​bluwy! - Exports astro/jsx/rehype.js with utilities to generate an Astro metadata object

  • #​10625 698c2d9 Thanks @​goulvenclech! - Adds the ability for multiple pages to use the same component as an entrypoint when building an Astro integration. This change is purely internal, and aligns the build process with the behaviour in the development server.

  • #​10906 7bbd664 Thanks @​Princesseuh! - Adds a new radio checkbox component to the dev toolbar UI library (astro-dev-toolbar-radio-checkbox)

  • #​10963 61f47a6 Thanks @​delucis! - Adds support for passing an inline Astro configuration object to getViteConfig()

    If you are using getViteConfig() to configure the Vitest test runner, you can now pass a second argument to control how Astro is configured. This makes it possible to configure unit tests with different Astro options when using Vitest’s workspaces feature.

    // vitest.config.ts
import { getViteConfig } from 'astro/config';

export default getViteConfig(
  /* Vite configuration */
  { test: {} },
  /* Astro configuration */
  {
    site: 'https://example.com',
    trailingSlash: 'never',
  },
);

  • #​10867 47877a7 Thanks @​ematipico! - Adds experimental rewriting in Astro with a new rewrite() function and the middleware next() function.

    The feature is available via an experimental flag in astro.config.mjs:

    export default defineConfig({
  experimental: {
    rewriting: true,
  },
});

    When enabled, you can use rewrite() to render another page without changing the URL of the browser in Astro pages and endpoints.

v4.7.1

Compare Source

Patch Changes

v4.7.0

Compare Source

Minor Changes

  • #​10665 7b4f284 Thanks @​Princesseuh! - Adds new utilities to ease the creation of toolbar apps including defineToolbarApp to make it easier to define your toolbar app and app and server helpers for easier communication between the toolbar and the server. These new utilities abstract away some of the boilerplate code that is common in toolbar apps, and lower the barrier of entry for app authors.

    For example, instead of creating an event listener for the app-toggled event and manually typing the value in the callback, you can now use the onAppToggled method. Additionally, communicating with the server does not require knowing any of the Vite APIs anymore, as a new server object is passed to the init function that contains easy to use methods for communicating with the server.

    import { defineToolbarApp } from "astro/toolbar";

export default defineToolbarApp({
  init(canvas, app, server) {

-    app.addEventListener("app-toggled", (e) => {
-      console.log(`App is now ${state ? "enabled" : "disabled"}`);.
-    });

+    app.onToggled(({ state }) => {
+        console.log(`App is now ${state ? "enabled" : "disabled"}`);
+    });

-    if (import.meta.hot) {
-      import.meta.hot.send("my-app:my-client-event", { message: "world" });
-    }

+    server.send("my-app:my-client-event", { message: "world" })

-    if (import.meta.hot) {
-      import.meta.hot.on("my-server-event", (data: {message: string}) => {
-        console.log(data.message);
-      });
-    }

+    server.on<{ message: string }>("my-server-event", (data) => {
+      console.log(data.message); // data is typed using the type parameter
+    });
  },
})

    Server helpers are also available on the server side, for use in your integrations, through the new toolbar object:

    "astro:server:setup": ({ toolbar }) => {
  toolbar.on<{ message: string }>("my-app:my-client-event", (data) => {
    console.log(data.message);
    toolbar.send("my-server-event", { message: "hello" });
  });
}

    This is a backwards compatible change and your your existing dev toolbar apps will continue to function. However, we encourage you to build your apps with the new helpers, following the updated Dev Toolbar API documentation.

  • #​10734 6fc4c0e Thanks @​Princesseuh! - Astro will now automatically check for updates when you run the dev server. If a new version is available, a message will appear in the terminal with instructions on how to update. Updates will be checked once per 10 days, and the message will only appear if the project is multiple versions behind the latest release.

    This behavior can be disabled by running astro preferences disable checkUpdates or setting the ASTRO_DISABLE_UPDATE_CHECK environment variable to false.

  • #​10762 43ead8f Thanks @​bholmesdev! - Enables type checking for JavaScript files when using the strictest TS config. This ensures consistency with Astro's other TS configs, and fixes type checking for integrations like Astro DB when using an astro.config.mjs.

    If you are currently using the strictest preset and would like to still disable .js files, set allowJS: false in your tsconfig.json.

Patch Changes

v4.6.4

Compare Source

Patch Changes

  • #​10846 3294f7a Thanks @​matthewp! - Prevent getCollection breaking in vitest

  • #​10856 30cf82a Thanks @​robertvanhoesel! - Prevents inputs with a name attribute of action or method to break ViewTransitions' form submission

  • #​10833 8d5f3e8 Thanks @​renovate! - Updates esbuild dependency to v0.20. This should not affect projects in most cases.

  • #​10801 204b782 Thanks @​rishi-raj-jain! - Fixes an issue where images in MD required a relative specifier (e.g. ./)

    Now, you can use the standard ![](relative/img.png) syntax in MD files for images colocated in the same folder: no relative specifier required!

    There is no need to update your project; your existing images will still continue to work. However, you may wish to remove any relative specifiers from these MD images as they are no longer necessary:

    - ![A cute dog](./dog.jpg)
+ ![A cute dog](dog.jpg)
<!-- This dog lives in the same folder as my article! -->

  • #​10841 a2df344 Thanks @​martrapp! - Due to regression on mobile WebKit browsers, reverts a change made for JavaScript animations during view transitions.

v4.6.3

Compare Source

Patch Changes

v4.6.2

Compare Source

Patch Changes

v4.6.1

Compare Source

Patch Changes

v4.6.0

Compare Source

Minor Changes

  • #​10591 39988ef8e2c4c4888543c973e06d9b9939e4ac95 Thanks @​mingjunlu! - Adds a new dev toolbar settings option to change the horizontal placement of the dev toolbar on your screen: bottom left, bottom center, or bottom right.

  • #​10689 683d51a5eecafbbfbfed3910a3f1fbf0b3531b99 Thanks @​ematipico! - Deprecate support for versions of Node.js older than v18.17.1 for Node.js 18, older than v20.0.3 for Node.js 20, and the complete Node.js v19 release line.

    This change is in line with Astro's Node.js support policy.

  • #​10678 2e53b5fff6d292b7acdf8c30a6ecf5e5696846a1 Thanks @​ematipico! - Adds a new experimental security option to prevent Cross-Site Request Forgery (CSRF) attacks. This feature is available only for pages rendered on demand:

    import { defineConfig } from 'astro/config';
export default defineConfig({
  experimental: {
    security: {
      csrfProtection: {
        origin: true,
      },
    },
  },
});

    Enabling this setting performs a check that the "origin" header, automatically passed by all modern browsers, matches the URL sent by each Request.

    This experimental "origin" check is executed only for pages rendered on demand, and only for the requests POST, PATCH, DELETEandPUTwith one of the followingcontent-type` headers: 'application/x-www-form-urlencoded', 'multipart/form-data', 'text/plain'.

    It the "origin" header doesn't match the pathname of the request, Astro will return a 403 status code and won't render the page.

  • #​10193 440681e7b74511a17b152af0fd6e0e4dc4014025 Thanks @​ematipico! - Adds a new i18n routing option manual to allow you to write your own i18n middleware:

    import { defineConfig } from 'astro/config';
// astro.config.mjs
export default defineConfig({
  i18n: {
    locales: ['en', 'fr'],
    defaultLocale: 'fr',
    routing: 'manual',
  },
});

    Adding routing: "manual" to your i18n config disables Astro's own i18n middleware and provides you with helper functions to write your own: redirectToDefaultLocale, notFound, and redirectToFallback:

    // middleware.js
import { redirectToDefaultLocale } from 'astro:i18n';
export const onRequest = defineMiddleware(async (context, next) => {
  if (context.url.startsWith('/about')) {
    return next();
  } else {
    return redirectToDefaultLocale(context, 302);
  }
});

    Also adds a middleware function that manually creates Astro's i18n middleware. This allows you to extend Astro's i18n routing instead of completely replacing it. Run middleware in combination with your own middleware, using the sequence utility to determine the order:

    import { defineMiddleware, sequence } from 'astro:middleware';
import { middleware } from 'astro:i18n'; // Astro's own i18n routing config

export const userMiddleware = defineMiddleware();

export const onRequest = sequence(
  userMiddleware,
  middleware({
    redirectToDefaultLocale: false,
    prefixDefaultLocale: true,
  }),
);

  • #​10671 9e14a78cb05667af9821948c630786f74680090d Thanks @​fshafiee! - Adds the httpOnly, sameSite, and secure options when deleting a cookie

Patch Changes

v4.5.18

Compare Source

Patch Changes

v4.5.17

Compare Source

Patch Changes

v4.5.16

Compare Source

Patch Changes

v4.5.15

Compare Source

Patch Changes

v4.5.14

Compare Source

Patch Changes

v4.5.13

Compare Source

Patch Changes

v4.5.12

Compare Source

Patch Changes

v4.5.11

Compare Source

Patch Changes

v4.5.10

Compare Source

Patch Changes

v4.5.9

Compare Source

Patch Changes

v4.5.8

Compare Source

Patch Changes

v4.5.7

Compare Source

Patch Changes

v4.5.6

Compare Source

Patch Changes

v4.5.5

Compare Source

Patch Changes

v4.5.4

Compare Source

Patch Changes

v4.5.3

Compare Source

Patch Changes

v4.5.2

Compare Source

Patch Changes

v4.5.1

Compare Source

Patch Changes

v4.5.0

Compare Source

Minor Changes

  • #​10206 dc87214141e7f8406c0fdf6a7f425dad6dea6d3e Thanks @​lilnasy! - Allows middleware to run when a matching page or endpoint is not found. Previously, a pages/404.astro or pages/[...catch-all].astro route had to match to allow middleware. This is now not necessary.

    When a route does not match in SSR deployments, your adapter may show a platform-specific 404 page instead of running Astro's SSR code. In these cases, you may still need to add a 404.astro or fallback route with spread params, or use a routing configuration option if your adapter provides one.

  • #​9960 c081adf998d30419fed97d8fccc11340cdc512e0 Thanks @​StandardGage! - Allows passing any props to the <Code /> component

  • #​10102 e3f02f5fb1cf0dae3c54beb3a4af3dbf3b06abb7 Thanks @​bluwy! - Adds a new experimental.directRenderScript configuration option which provides a more reliable strategy to prevent scripts from being executed in pages where they are not used.

    This replaces the experimental.optimizeHoistedScript flag introduced in v2.10.4 to prevent unused components' scripts from being included in a page unexpectedly. That experimental option no longer exists and must be removed from your configuration, whether or not you enable directRenderScript:

    // astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
	experimental: {
-		optimizeHoistedScript: true,
+		directRenderScript: true
	}
});

    With experimental.directRenderScript configured, scripts are now directly rendered 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> and multiple scripts on a page are no longer bundled together. If you enable this option, you should check that all your <script> tags behave as expected.

    This option will be enabled by default in Astro 5.0.

  • #​10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @​bluwy! - Stabilizes markdown.shikiConfig.experimentalThemes as markdown.shikiConfig.themes. No behaviour changes are made to this option.

  • #​10189 1ea0a25b94125e4f6f2ac82b42f638e22d7bdffd Thanks @​peng! - Adds the option to pass an object to build.assetsPrefix. This allows for the use of multiple CDN prefixes based on the target file type.

    When passing an object to build.assetsPrefix, you must also specify a fallback domain to be used for all other file types not specified.

    Specify a file extension as the key (e.g. 'js', 'png') and the URL serving your assets of that file type as the value:

    // astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  build: {
    assetsPrefix: {
      js: 'https://js.cdn.example.com',
      mjs: 'https://js.cdn.example.com', // if you have .mjs files, you must add a new entry like this
      png: 'https://images.cdn.example.com',
      fallback: 'https://generic.cdn.example.com',
    },
  },
});

  • #​10252 3307cb34f17159dfd3f03144697040fcaa10e903 Thanks @​Princesseuh! - Adds support for emitting warning and info notifications from dev toolbar apps.

    When using the toggle-notification event, the severity can be specified through detail.level:

    eventTarget.dispatchEvent(
  new CustomEvent('toggle-notification', {
    detail: {
      level: 'warning',
    },
  }),
);

  • #​10186 959ca5f9f86ef2c0a5a23080cc01c25f53d613a9 Thanks @​Princesseuh! - Adds the ability to set colors on all the included UI elements for dev toolbar apps. Previously, only badge and buttons could be customized.

  • #​10136 9cd84bd19b92fb43ae48809f575ee12ebd43ea8f Thanks @​matthewp! - Changes the default behavior of transition:persist to update the props of persisted islands upon navigation. Also adds a new view transitions option transition:persist-props (default: false) to prevent props from updating as needed.

    Islands which have the transition:persist property to keep their state when using the <ViewTransitions /> router will now have their props updated upon navigation. This is useful in cases where the component relies on page-specific props, such as the current page title, which should update upon navigation.

    For example, the component below is set to persist across navigation. This component receives a products props and might have some internal state, such as which filters are applied:

    <ProductListing transition:persist products={products} />

    Upon navigation, this component persists, but the desired products might change, for example if you are visiting a category of products, or you are performing a search.

    Previously the props would not change on navigation, and your island would have to handle updating them externally, such as with API calls.

    With this change the props are now updated, while still preserving state.

    You can override this new default behavior on a per-component basis using transition:persist-props=true to persist both props and state during navigation:

    <ProductListing transition:persist-props="true" products={products} />

  • #​9977 0204b7de37bf626e1b97175b605adbf91d885386 Thanks @​OliverSpeir! - Supports adding the data-astro-rerun attribute on script tags so that they will be re-executed after view transitions

    <script is:inline data-astro-rerun>
  ...
</script>

  • #​10145 65692fa7b5f4440c644c8cf3dd9bc50103d2c33b Thanks @​alexanderniebuhr! - Adds experimental JSON Schema support for content collections.

    This feature will auto-generate a JSON Schema for content collections of type: 'data' which can be used as the $schema value for TypeScript-style autocompletion/hints in tools like VSCode.

    To enable this feature, add the experimental flag:

    import { defineConfig } from 'astro/config';

export default defineConfig({
	experimental: {
+		contentCollectionJsonSchema: true
	}
});

    This experimental implementation requires you to manually reference the schema in each data entry file of the collection:

    // src/content/test/entry.json
{
+  "$schema": "../../../.astro/collections/test.schema.json",
  "test": "test"
}

    Alternatively, you can set this in your VSCode json.schemas settings:

    "json.schemas": [
  {
    "fileMatch": [
      "/src/content/test/**"
    ],
    "url": "../../../.astro/collections/test.schema.json"
  }
]

    Note that this initial implementation uses a library with known issues for advanced Zod schemas, so you may wish to consult these limitations before enabling the experimental flag.

  • #​10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @​bluwy! - Migrates shikiji to shiki 1.0

  • #​10268 2013e70bce16366781cc12e52823bb257fe460c0 Thanks @​Princesseuh! - Adds support for page mutations to the audits in the dev toolbar. Astro will now rerun the audits whenever elements are added or deleted from the page.

  • #​10217 5c7862a9fe69954f8630538ebb7212cd04b8a810 Thanks @​Princesseuh! - Updates the UI for dev toolbar audits with new information

Patch Changes

v4.4.15

Compare Source

Patch Changes

v4.4.14

Compare Source

Patch Changes

v4.4.13

Compare Source

Patch Changes

v4.4.12

Compare Source

Patch Changes

v4.4.11

Compare Source

Patch Changes

v4.4.10

Compare Source

Patch Changes

v4.4.9

Compare Source

Patch Changes

v4.4.8

Compare Source

Patch Changes

v4.4.7

Compare Source

Patch Changes

v4.4.6

Compare Source

Patch Changes

v4.4.5

Compare Source

Patch Changes

v4.4.4

Compare Source

Patch Changes

v4.4.3

Compare Source

Patch Changes

v4.4.2

Compare Source

Patch Changes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This MR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this MR, check this box

This MR has been generated by Renovate Bot. The local configuration can be found in the local Renovate Bot repository.

Edited by Housekeeper (bot)

Merge request reports