astro@4.10.2

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

@astrojs/vercel@7.7.0

Minor Changes

• #11199 2bdca27 Thanks @florian-lefebvre! - Adds support for experimental astro:env released in Astro 4.10

@astrojs/partytown@2.1.1

Patch Changes

• #11083 416c4ac Thanks @V3RON! - Prevent Partytown from crashing when View Transitions are enabled

  When View Transitions are turned on, Partytown executes on every transition.
  It's not meant to be like that, and therefore it breaks the integration completely.
  Starting from now, Partytown will be executed only once.

@astrojs/node@8.3.0

Minor Changes

• #11199 2bdca27 Thanks @florian-lefebvre! - Adds support for experimental astro:env released in Astro 4.10

@astrojs/db@0.11.5

Patch Changes

• #11216 29463df Thanks @OliverSpeir! - Export type Database from @astrojs/db/runtime

• Updated dependencies []:

  • @astrojs/studio@0.1.0

astro@4.10.1

Patch Changes

• #11198 8b9a499 Thanks @florian-lefebvre! - Fixes a case where astro:env getSecret would not retrieve environment variables properly in dev and build modes

• #11206 734b98f Thanks @florian-lefebvre! - BREAKING CHANGE to the experimental astro:env feature only

  Updates the adapter astro:env entrypoint from astro:env/setup to astro/env/setup

• #11205 8c45391 Thanks @Nin3lee! - Fixes a typo in the config reference

@astrojs/node@8.2.6

Patch Changes

• #11202 d0248bc Thanks @dkobierski! - Fixes suppressed logs when error occurs

astro@4.10.0

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:

  ---
  import { PUBLIC_APP_ID } from 'astro:env/client';
  import { PUBLIC_API_URL, getSecret } from 'astro:env/server';
  const API_TOKEN = getSecret('API_TOKEN');
  
  const data = await fetch(`${PUBLIC_API_URL}/users`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${API_TOKEN}`,
    },
    body: JSON.stringify({ appId: PUBLIC_APP_ID }),
  });
  ---

  To define the data type and properties of your environment variables, declare a schema in your Astro config in experimental.env.schema. The envField helper allows you define your variable as a string, number, or boolean and pass properties in an object:

  // astro.config.mjs
  import { defineConfig, envField } from 'astro/config';
  
  export default defineConfig({
    experimental: {
      env: {
        schema: {
          PUBLIC_API_URL: envField.string({ context: 'client', access: 'public', optional: true }),
          PUBLIC_PORT: envField.number({ context: 'server', access: 'public', default: 4321 }),
          API_SECRET: envField.string({ context: 'server', access: 'secret' }),
        },
      },
    },
  });

  There are three kinds of environment variables, determined by the combination of context (client or server) and access (private or public) settings defined in your env.schema:

  • Public client variables: These variables end up in both your final client and server bundles, and can be accessed from both client and server through the astro:env/client module:

    import { PUBLIC_API_URL } from 'astro:env/client';

  • Public server variables: These variables end up in your final server bundle and can be accessed on the server through the astro:env/server module:

    import { PUBLIC_PORT } from 'astro:env/server';

  • Secret server variables: These variables are not part of your final bundle and can be accessed on the server through the getSecret() helper function available from the astro:env/server module:

    import { getSecret } from 'astro:env/server';
    
    const API_SECRET = getSecret('API_SECRET'); // typed
    const SECRET_NOT_IN_SCHEMA = getSecret('SECRET_NOT_IN_SCHEMA'); // string | undefined

  Note: Secret client variables are not supported because there is no safe way to send this data to the client. Therefore, it is not possible to configure both context: "client" and access: "secret" in your schema.

  To learn more, check out the documentation.

Patch Changes

• #11192 58b10a0 Thanks @liruifengv! - Improves DX by throwing the original AstroUserError when an error is thrown inside a .mdx file.

• #11136 35ef53c Thanks @ematipico! - Errors that are emitted during a rewrite are now bubbled up and shown to the user. A 404 response is not returned anymore.

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

• #11144 803dd80 Thanks @ematipico! - BREAKING CHANGE to the experimental Container API only

  Changes the type of the renderers option of the AstroContainer::create function and adds a dedicated function loadRenderers() to load the rendering scripts from renderer integration packages (@astrojs/react, @astrojs/preact, @astrojs/solid-js, @astrojs/svelte, @astrojs/vue, @astrojs/lit, and @astrojs/mdx).

  You no longer need to know the individual, direct file paths to the client and server rendering scripts for each renderer integration package. Now, there is a dedicated function to load the renderer from each package, which is available from getContainerRenderer():

  import { experimental_AstroContainer as AstroContainer } from 'astro/container';
  import ReactWrapper from '../src/components/ReactWrapper.astro';
  import { loadRenderers } from "astro:container";
  import { getContainerRenderer } from "@astrojs/react";
  
  test('ReactWrapper with react renderer', async () => {
  + const renderers = await loadRenderers([getContainerRenderer()])
  - const renderers = [
  - {
  -  name: '@astrojs/react',
  -   clientEntrypoint: '@astrojs/react/client.js',
  -   serverEntrypoint: '@astrojs/react/server.js',
  -  },
  - ];
    const container = await AstroContainer.create({
      renderers,
    });
    const result = await container.renderToString(ReactWrapper);
  
    expect(result).toContain('Counter');
    expect(result).toContain('Count: <!-- -->5');
  });

  The new loadRenderers() helper function is available from astro:container, a virtual module that can be used when running the Astro container inside vite.

• #11136 35ef53c Thanks @ematipico! - It's not possible anymore to use Astro.rewrite("/404") inside static pages. This isn't counterproductive because Astro will end-up emitting a page that contains the HTML of 404 error page.

  It's still possible to use Astro.rewrite("/404") inside on-demand pages, or pages that opt-out from prerendering.

• #11191 6e29a17 Thanks @matthewp! - Fixes a case where Astro.url would be incorrect when having build.format set to 'preserve' in the Astro config

• #11182 40b0b4d Thanks @ematipico! - Fixes an issue where Astro.rewrite wasn't carrying over the body of a Request in on-demand pages.

• #11194 97fbe93 Thanks @ematipico! - Fixes an issue where the function getViteConfig wasn't returning the correct merged Astro configuration

@astrojs/vue@4.4.0

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 '@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');
  });

@astrojs/svelte@5.5.0

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 '@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');
  });