@astrojs/markdoc@0.11.5-beta.0

Patch Changes

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

@astrojs/db@0.14.0-beta.1

Minor 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 []:
  • @astrojs/studio@0.1.1

astro@4.15.6

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

astro@4.15.5

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

@astrojs/mdx@3.1.6

Patch Changes

• #11975 c9ae7b1 Thanks @bluwy! - Handles nested root hast node when optimizing MDX

astro@5.0.0-alpha.8

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

astro@5.0.0-alpha.7

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>

@astrojs/underscore-redirects@0.4.0-alpha.0

Minor Changes

• #11989 3e70853 Thanks @florian-lefebvre! - Updates the type from RouteData to IntegrationRouteData

astro@5.0.0-alpha.6

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

astro@5.0.0-alpha.5

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:

  ---
  // src/pages/index.astro
  
  export const prerender = true;
  ---

  // src/middleware.js
  
  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