Changelog

• 4.15.7

  Sep 17, 2024

  🐞 Patch Changes

  • #12000 a2f8c5d Thanks @ArmandPhilippot! - Fixes an outdated link used to document Content Layer API

  • #11915 0b59fe7 Thanks @azhirov! - Fix: prevent island from re-rendering when using transition:persist (#11854)

• 5.0.0-beta.1

  Sep 17, 2024

  ✨ Major Changes

  • #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.

  🐞 Patch Changes

  • Updated dependencies [5608338]:
    • @astrojs/markdown-remark@6.0.0-beta.1
• 5.0.0-alpha.8

  Sep 13, 2024

  ✨ Major Changes

  • #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.

  • #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,
    });

  🍿 Minor Changes

  • #11980 a604a0c Thanks @matthewp! - 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.

  🐞 Patch Changes

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

  • #11991 d7a396c Thanks @matthewp! - Update error link to on-demand rendering guide

• 4.15.6

  Sep 13, 2024

  🐞 Patch Changes

  • #11993 ffba5d7 Thanks @matthewp! - Fix getStaticPaths regression

    This reverts a previous change meant to remove a dependency, to fix a regression with multiple nested spread routes.

  • #11964 06eff60 Thanks @TheOtterlord! - Add wayland (wl-copy) support to astro info

• 5.0.0-alpha.7

  Sep 13, 2024

  ✨ Major Changes

  • #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) {
    
    }

  • #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',
        },
      },
    });

  • #11806 f7f2338 Thanks @Princesseuh! - 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.

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

    import type {RouteData} from 'astro';
    import type {IntegrationRouteData} from "astro"
    
    function useRoute(route: RouteData) {
    function useRoute(route: IntegrationRouteData) {
    
    }

  • #11864 ee38b3a Thanks @ematipico! - ### [changed]: RouteData.distURL is now an array In Astro v4.x, RouteData.distURL was undefined or a URL

    Astro v5.0, RouteData.distURL is undefined or an array of URL. This was a bug, because a route can generate multiple files on disk, especially when using dynamic routes such as [slug] or [...slug].

    What should I do?

    Update your code to handle RouteData.distURL as an array.

    if (route.distURL) {
      if (route.distURL.endsWith('index.html')) {
        // do something
      }
      for (const url of route.distURL) {
        if (url.endsWith('index.html')) {
          // do something
        }
      }
    }

  🍿 Minor Changes

  • #11806 f7f2338 Thanks @Princesseuh! - 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.

  • #11955 d813262 Thanks @matthewp! - Server Islands introduced behind an experimental flag in v4.12.0 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.

    ---
    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:

    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 for more about this feature.

  • #11806 f7f2338 Thanks @Princesseuh! - Adds a new limited value for the different properties of supportedAstroFeatures for adapters, which indicates that the adapter is compatible with the feature, but with some limitations. This is useful for adapters that support a feature, but not in all cases or with all options.

  • #11925 74722cb Thanks @florian-lefebvre! - Updates astro/config import to reference astro/client types

    When importing astro/config, types from astro/client will be made automatically available to your project. If your project tsconfig.json changes how references behave, you’ll still have access to these types after running astro sync.

  🐞 Patch Changes

  • #11974 60211de Thanks @ascorbic! - Exports the RenderResult type

  • #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:

    ---
    import { actions } from 'astro:actions';
    ---
    
    <!--Create-->
    <form action={actions.changeUser} method="POST">
      <input type="hidden" name="type" value="create" />
      <input type="text" name="name" required />
      <input type="email" name="email" required />
      <button type="submit">Create User</button>
    </form>
    
    <!--Update-->
    <form action={actions.changeUser} method="POST">
      <input type="hidden" name="type" value="update" />
      <input type="hidden" name="id" value="user-123" />
      <input type="text" name="name" required />
      <input type="email" name="email" required />
      <button type="submit">Update User</button>
    </form>

• 4.15.5

  Sep 13, 2024

  🐞 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:

    ---
    import { actions } from 'astro:actions';
    ---
    
    <!--Create-->
    <form action={actions.changeUser} method="POST">
      <input type="hidden" name="type" value="create" />
      <input type="text" name="name" required />
      <input type="email" name="email" required />
      <button type="submit">Create User</button>
    </form>
    
    <!--Update-->
    <form action={actions.changeUser} method="POST">
      <input type="hidden" name="type" value="update" />
      <input type="hidden" name="id" value="user-123" />
      <input type="text" name="name" required />
      <input type="email" name="email" required />
      <button type="submit">Update User</button>
    </form>

  • #11968 86ad1fd Thanks @NikolaRHristov! - Fixes a typo in the server island JSDoc

  • #11983 633eeaa Thanks @uwej711! - Remove dependency on path-to-regexp

• 5.0.0-alpha.6

  Sep 10, 2024

  ✨ Major Changes

  • #11941 b6a5f39 Thanks @Princesseuh! - 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.

    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.

  🍿 Minor Changes

  • #11941 b6a5f39 Thanks @Princesseuh! - 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.

    {
      '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.

  • #11941 b6a5f39 Thanks @Princesseuh! - 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).

  🐞 Patch Changes

  • #11960 4410130 Thanks @ascorbic! - Fixes an issue where the refresh context data was not passed correctly to content layer loaders

  • #11952 50a0146 Thanks @ascorbic! - 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.

    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()),
      }),
    });

• 5.0.0-alpha.5

  Sep 9, 2024

  ✨ Major Changes

  • #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.

  🍿 Minor Changes

  • #11875 a8a3d2c Thanks @florian-lefebvre! - Adds a new property isPrerendered to the globals Astro and APIContext . This boolean value represents whether or not the current page is prerendered:

    ---
    export const prerender = true;
    ---

    export const onRequest = (ctx, next) => {
      console.log(ctx.isPrerendered); // it will log true
      return next();
    };

  🐞 Patch Changes

  • #11927 5b4e3ab Thanks @florian-lefebvre! - Updates the env configuration reference docs to include a full API reference for envField.

  • #11943 fa4671c Thanks @sarah11918! - Updates error messages that assume content collections are located in src/content/ with more generic language

• 4.15.4

  Sep 6, 2024

  🐞 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

• 4.15.3

  Sep 5, 2024

  🐞 Patch Changes

  • #11902 d63bc50 Thanks @ascorbic! - Fixes case where content layer did not update during clean dev builds on Linux and Windows

  • #11886 7ff7134 Thanks @matthewp! - Fixes a missing error message when actions throws during astro sync

  • #11904 ca54e3f Thanks @wtchnm! - perf(assets): avoid downloading original image when using cache

• 5.0.0-alpha.4

  Sep 4, 2024

  ✨ Major Changes

  • #11859 3804711 Thanks @florian-lefebvre! - 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:

    {
        "extends": "astro/tsconfigs/base",
        "include": ["**/*", ".astro/types.d.ts"],
        "exclude": ["dist"]
    }

  🍿 Minor Changes

  • #11911 c3dce83 Thanks @ascorbic! - The Content Layer API introduced behind a flag in 4.14.0 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.

    If you previously used this feature, you can now remove the experimental.contentLayer flag from your Astro config:

    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:

    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:

    ---
    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:

    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 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. Here’s how to load content using an RSS/Atom feed loader:

    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.

  🐞 Patch Changes

  • #11902 d63bc50 Thanks @ascorbic! - Fixes case where content layer did not update during clean dev builds on Linux and Windows

  • #11914 b5d827b Thanks @ascorbic! - 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.

• 5.0.0-alpha.3

  Sep 3, 2024

  ✨ Major Changes

  • #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.

  • #11825 560ef15 Thanks @bluwy! - 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 for more information).

    Code blocks in .mdoc files and <Code /> component do not use the internal Shiki rehype plugin and are unaffected.

  • #11819 2bdde80 Thanks @bluwy! - 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.

  🐞 Patch Changes

  • #11878 334948c Thanks @ascorbic! - 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.

     {
        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 }));
                        }
                    });
                });
            }
        }
    }

  • Updated dependencies [3ab3b4e, 560ef15, 3ab3b4e]:

    • @astrojs/markdown-remark@6.0.0-alpha.1
• 4.15.2

  Sep 2, 2024

  🐞 Patch Changes

  • #11870 8e5257a Thanks @ArmandPhilippot! - Fixes typo in documenting the fallbackType property in i18n routing

  • #11884 e450704 Thanks @ascorbic! - Correctly handles content layer data where the transformed value does not match the input schema

  • #11900 80b4a18 Thanks @delucis! - Fixes the user-facing type of the new i18n.routing.fallbackType option to be optional

• 5.0.0-alpha.2

  Aug 30, 2024

  ✨ Major Changes

  • #11826 7315050 Thanks @matthewp! - 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, 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:

    const posts = Astro.glob('./posts/*.md');
    const posts = Object.values(import.meta.glob('./posts/*.md', { eager: true }));

  • #11827 a83e362 Thanks @matthewp! - 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.

  • #11253 4e5cc5a Thanks @kevinzunigacuellar! - Changes the data returned for page.url.current, page.url.next, page.url.prev, page.url.first and page.url.last to include the value set for base in your Astro config.

    Previously, you had to manually prepend your configured value for base to the URL path. Now, Astro automatically includes your base value in next and prev URLs.

    If you are using the paginate() function for “previous” and “next” URLs, remove any existing base value as it is now added for you:

    ---
    export async function getStaticPaths({ paginate }) {
      const astronautPages = [{
        astronaut: 'Neil Armstrong',
      }, {
        astronaut: 'Buzz Aldrin',
      }, {
        astronaut: 'Sally Ride',
      }, {
        astronaut: 'John Glenn',
      }];
      return paginate(astronautPages, { pageSize: 1 });
    }
    const { page } = Astro.props;
    // `base: /'docs'` configured in `astro.config.mjs`
     const prev = "/docs" + page.url.prev;
     const prev = page.url.prev;
    ---
    <a id="prev" href={prev}>Back</a>

  🍿 Minor Changes

  • #11698 05139ef Thanks @ematipico! - 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]:

    ---
    const route = Astro.routePattern;
    console.log(route); // it will log "blog/[slug]"
    ---

    export const GET = (ctx) => {
      console.log(ctx.routePattern); // it will log src/pages/index.js
      return new Response.json({ loreum: 'ipsum' });
    };

  🐞 Patch Changes

  • #11791 9393243 Thanks @bluwy! - 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.

  • #11767 d1bd1a1 Thanks @ascorbic! - Refactors content layer sync to use a queue

• 4.15.1

  Aug 29, 2024

  🐞 Patch Changes

  • #11872 9327d56 Thanks @bluwy! - Fixes astro add importing adapters and integrations

  • #11767 d1bd1a1 Thanks @ascorbic! - Refactors content layer sync to use a queue

• 4.15.0

  Aug 29, 2024
  

  🍿 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.

    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.

    z will no longer be exposed from astro:actions. To use z in your actions, import it from astro:schema instead:

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

  • #11843 5b4070e Thanks @bholmesdev! - The Astro Actions API introduced behind a flag in v4.8.0 is no longer experimental and is available for general use.

    Astro Actions allow you to define and call backend functions with type-safety, performing data fetching, JSON parsing, and input validation for you.

    Actions can be called from client-side components and HTML forms. This gives you to flexibility to build apps using any technology: React, Svelte, HTMX, or just plain Astro components. This example calls a newsletter action and renders the result using an Astro component:

    ---
    import { actions } from 'astro:actions';
    const result = Astro.getActionResult(actions.newsletter);
    ---
    
    {result && !result.error && <p>Thanks for signing up!</p>}
    <form method="POST" action={actions.newsletter}>
      <input type="email" name="email" />
      <button>Sign up</button>
    </form>

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

    import { defineConfig } from 'astro'
    
    export default defineConfig({
      experimental: {
        actions: true,
      }
    })

    If you have been waiting for stabilization before using Actions, you can now do so.

    For more information and usage examples, see our brand new Actions guide.

  🐞 Patch Changes

  • #11677 cb356a5 Thanks @ematipico! - Fixes a bug in the logic of Astro.rewrite() which led to the value for base, if configured, being automatically prepended to the rewrite URL passed. This was unintended behavior and has been corrected, and Astro now processes the URLs exactly as passed.

    If you use the rewrite() function on a project that has base configured, you must now prepend the base to your existing rewrite URL:

    export default defineConfig({
      base: '/blog',
    });

    export function onRequest(ctx, next) {
      return ctx.rewrite("/about")
      return ctx.rewrite("/blog/about")
    }

  • #11862 0e35afe Thanks @ascorbic! - BREAKING CHANGE to experimental content layer loaders only!

    Passes AstroConfig instead of AstroSettings object to content layer loaders.

    This will not affect you unless you have created a loader that uses the settings object. If you have, you will need to update your loader to use the config object instead.

    export default function myLoader() {
      return {
        name: 'my-loader'
       async load({ settings }) {
         const base = settings.config.base;
       async load({ config }) {
         const base = config.base;
          // ...
        }
      }
    }

    Other properties of the settings object are private internals, and should not be accessed directly. If you think you need access to other properties, please open an issue to discuss your use case.

  • #11772 6272e6c Thanks @bluwy! - Uses magicast to update the config for astro add

  • #11845 440a4be Thanks @bluwy! - Replaces execa with tinyexec internally

  • #11858 8bab233 Thanks @ascorbic! - Correctly resolves content layer images when filePath is not set

• 4.14.6

  Aug 28, 2024

  🐞 Patch Changes

  • #11847 45b599c Thanks @ascorbic! - Fixes a case where Vite would be imported by the SSR runtime, causing bundling errors and bloat.

  • #11822 6fcaab8 Thanks @bluwy! - Marks internal vite-plugin-fileurl plugin with enforce: 'pre'

  • #11713 497324c Thanks @voidfill! - Prevents prefetching of the same urls with different hashes.

  • #11814 2bb72c6 Thanks @eduardocereto! - Updates the documentation for experimental Content Layer API with a corrected code example

  • #11842 1ffaae0 Thanks @stephan281094! - Fixes a typo in the MissingImageDimension error message

  • #11828 20d47aa Thanks @bholmesdev! - Improves error message when invalid data is returned by an Action.

• 5.0.0-alpha.1

  Aug 23, 2024

  ✨ 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.

  • #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:

    ---
    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>

  • #11788 7c0ccfc Thanks @ematipico! - 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:

    export default defineConfig({
      security: {
        checkOrigin: false
      }
    })

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

  • #11782 9a2aaa0 Thanks @Princesseuh! - 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.

    ---
    import * as myPost from "../post.md";
    
     const content = myPost.compiledContent();
     const content = await myPost.compiledContent();
    ---
    
    <Fragment set:html={content} />

  • #11770 cfa6a47 Thanks @Princesseuh! - 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.

     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

  🐞 Patch Changes

  • #11780 c6622ad Thanks @Princesseuh! - Deprecates the Squoosh image service, to be removed in Astro 5.0. We recommend migrating to the default Sharp service.

  • #11732 4cd6c43 Thanks @matthewp! - 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.

  • #11773 86a3391 Thanks @ematipico! - Changes messages logged when using unsupported, deprecated, or experimental adapter features for clarity

  • #11774 c6400ab Thanks @florian-lefebvre! - Fixes the path returned by injectTypes

  • #11771 49650a4 Thanks @florian-lefebvre! - Fixes an error thrown by astro sync when an astro:env virtual module is imported inside the Content Collections config

  • #11744 b677429 Thanks @bluwy! - Disables the WebSocket server when creating a Vite server for loading config files

• 4.14.5

  Aug 22, 2024

  🐞 Patch Changes

  • #11809 62e97a2 Thanks @bholmesdev! - Fixes usage of .transform(), .refine(), .passthrough(), and other effects on Action form inputs.

  • #11812 260c4be Thanks @bholmesdev! - Exposes ActionAPIContext type from the astro:actions module.

  • #11813 3f7630a Thanks @bholmesdev! - Fixes unexpected undefined value when calling an action from the client without a return value.

• 4.14.4

  Aug 21, 2024

  🐞 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.