astro

Patch Changes

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

• Updated dependencies []:

  • @astrojs/[email protected]

Patch Changes

• #11717 423614e Thanks @bluwy! - Fixes stack trace location when failed to parse an MDX file with frontmatter

Patch Changes

• #11766 d12dcbf Thanks @bluwy! - Fixes initial git commit when initializing git

Major Changes

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

• #11715 d74617c Thanks @Princesseuh! - Refactor the exported types from the astro module. There should normally be no breaking changes, but if you relied on some previously deprecated types, these might now have been fully removed.

  In most cases, updating your code to move away from previously deprecated APIs in previous versions of Astro should be enough to fix any issues.

• #11660 e90f559 Thanks @bluwy! - Fixes attribute rendering for non-boolean HTML attributes with boolean values to match proper attribute handling in browsers.

  Previously, non-boolean attributes may not have included their values when rendered to HTML. In Astro v5.0, the values are now explicitly rendered as ="true" or ="false"

  In the following .astro examples, only allowfullscreen is a boolean attribute:

  <!-- src/pages/index.astro --><!-- `allowfullscreen` is a boolean attribute -->
  <p allowfullscreen={true}></p>
  <p allowfullscreen={false}></p>
  
  <!-- `inherit` is *not* a boolean attribute -->
  <p inherit={true}></p>
  <p inherit={false}></p>
  
  <!-- `data-*` attributes are not boolean attributes -->
  <p data-light={true}></p>
  <p data-light={false}></p>
  

  Astro v5.0 now preserves the full data attribute with its value when rendering the HTML of non-boolean attributes:

    <p allowfullscreen></p>
    <p></p>
  
    <p inherit="true"></p>
  - <p inherit></p>
  + <p inherit="false"></p>
  
  - <p data-light></p>
  + <p data-light="true"></p>
  - <p></p>
  + <p data-light="false"></p>
  

  If you rely on attribute values, for example to locate elements or to conditionally render, update your code to match the new non-boolean attribute values:

  - el.getAttribute('inherit') === ''
  + el.getAttribute('inherit') === 'false'
  
  - el.hasAttribute('data-light')
  + el.dataset.light === 'true'
  

• #11714 8a53517 Thanks @matthewp! - Remove support for functionPerRoute

  This change removes support for the functionPerRoute option both in Astro and @astrojs/vercel.

  This option made it so that each route got built as separate entrypoints so that they could be loaded as separate functions. The hope was that by doing this it would decrease the size of each function. However in practice routes use most of the same code, and increases in function size limitations made the potential upsides less important.

  Additionally there are downsides to functionPerRoute, such as hitting limits on the number of functions per project. The feature also never worked with some Astro features like i18n domains and request rewriting.

  Given this, the feature has been removed from Astro.

Patch Changes

• #11745 89bab1e Thanks @bluwy! - Prints prerender dynamic value usage warning only if it's used

• #11730 2df49a6 Thanks @florian-lefebvre! - Simplifies path operations of astro sync

• Updated dependencies [83a2a64]:

  • @astrojs/[email protected]

Major Changes

• #11714 8a53517 Thanks @matthewp! - Remove support for functionPerRoute

  This change removes support for the functionPerRoute option both in Astro and @astrojs/vercel.

  This option made it so that each route got built as separate entrypoints so that they could be loaded as separate functions. The hope was that by doing this it would decrease the size of each function. However in practice routes use most of the same code, and increases in function size limitations made the potential upsides less important.

  Additionally there are downsides to functionPerRoute, such as hitting limits on the number of functions per project. The feature also never worked with some Astro features like i18n domains and request rewriting.

  Given this, the feature has been removed from Astro.

Minor Changes

• #11728 5ea02b1 Thanks @matthewp! - Deprecates the functionPerRoute option

  This option is now deprecated, and will be removed entirely in Astro v5.0. We suggest removing this option from your configuration as soon as you are able to:

  import { defineConfig } from 'astro/config';
  import vercel from '@astrojs/vercel/serverless';
  
  export default defineConfig({
    // ...
    output: 'server',
    adapter: vercel({
  -     functionPerRoute: true,
    }),
  });
  

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, e90f559, 2df49a6, 8a53517]:
  • [email protected]

Major Changes

• #11661 83a2a64 Thanks @bluwy! - Renames the following CSS variables theme color token names to better align with the Shiki v1 defaults:

  • --astro-code-color-text => --astro-code-foreground
  • --astro-code-color-background => --astro-code-background

  You can perform a global find and replace in your project to migrate to the new token names.

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, e90f559, 2df49a6, 8a53517]:
  • [email protected]

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, e90f559, 2df49a6, 8a53517]:
  • [email protected]

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, e90f559, 2df49a6, 8a53517]:
  • [email protected]

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, 83a2a64, e90f559, 2df49a6, 8a53517]:
  • [email protected]
  • @astrojs/[email protected]

Patch Changes

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, e90f559, 2df49a6, 8a53517]:
  • [email protected]

Patch Changes

• #11717 423614e Thanks @bluwy! - Fixes stack trace location when failed to parse an MDX file with frontmatter

• Updated dependencies [b6fbdaa, 89bab1e, d74617c, 83a2a64, e90f559, 2df49a6, 8a53517]:

  • [email protected]
  • @astrojs/[email protected]

Patch Changes

• #11766 d12dcbf Thanks @bluwy! - Fixes initial git commit when initializing git

Patch Changes

• #11733 391324d Thanks @bluwy! - Reverts back to yargs-parser package for CLI argument parsing

Patch Changes

• #11733 391324d Thanks @bluwy! - Reverts back to arg package for CLI argument parsing

Patch Changes

• #11733 391324d Thanks @bluwy! - Reverts back to arg package for CLI argument parsing

Patch Changes

• #11733 391324d Thanks @bluwy! - Reverts back to yargs-parser package for CLI argument parsing

• Updated dependencies []:

  • @astrojs/[email protected]

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

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:

  ---
  // src/components/Card.astro
  import { Code } from 'astro:components';
  import { transformerMetaHighlight } from '@shikijs/transformers';
  ---
  
  <Code code={code} lang="js" transformers={[transformerMetaHighlight()]} meta="{1,3}" />
  

• #11360 a79a8b0 Thanks @ascorbic! - Adds support for Intellisense features (e.g. code completion, quick hints) for your content collection entries in compatible editors under the experimental.contentIntellisense flag.

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

  When enabled, this feature will generate and add JSON schemas to the .astro directory in your project. These files can be used by the Astro language server to provide Intellisense inside content files (.md, .mdx, .mdoc).

  Note that at this time, this also require enabling the astro.content-intellisense option in your editor, or passing the contentIntellisense: true initialization parameter to the Astro language server for editors using it directly.

  See the experimental content Intellisense docs for more information updates as this feature develops.

• #11360 a79a8b0 Thanks @ascorbic! - Adds experimental support for the Content Layer API.

  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.

  Getting started

  To try out the new Content Layer API, enable it in your Astro config:

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

  You can then create collections in your src/content/config.ts using the Content Layer API.

  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:

  // src/content/config.ts
  import { defineCollection, z } from 'astro:content';
  import { glob } from 'astro/loaders';
  
  const blog = defineCollection({
    // The ID is a slug generated from the path of the file relative to `base`
    loader: glob({ pattern: '**/*.md', base: './src/data/blog' }),
    schema: z.object({
      title: z.string(),
      description: z.string(),
      publishDate: z.coerce.date(),
    }),
  });
  
  export const collections = { blog };
  

  You can then query using the existing content collections functions, and enjoy 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:

  // src/content/config.ts
  const countries = defineCollection({
    loader: async () => {
      const response = await fetch('https://restcountries.com/v3.1/all');
      const data = await response.json();
      // Must return an array of entries with an id property,
      // or an object with IDs as keys and entries as values
      return data.map((country) => ({
        id: country.cca3,
        ...country,
      }));
    },
    // optionally add a schema to validate the data and make it type-safe for users
    // schema: z.object...
  });
  
  export const collections = { countries };
  

  For more advanced loading logic, you can define an object loader. This allows incremental updates and conditional loading, and gives full access to the data store. It also allows a loader to define its own schema, including generating it dynamically based on the source API. See the the Content Layer API RFC 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:

  // src/content/config.ts
  import { defineCollection } from 'astro:content';
  import { feedLoader } from '@ascorbic/feed-loader';
  
  const podcasts = defineCollection({
    loader: feedLoader({
      url: 'https://feeds.99percentinvisible.org/99percentinvisible',
    }),
  });
  
  export const collections = { podcasts };
  

  Learn more

  To find out more about using the Content Layer API, check out the Content Layer RFC and share your feedback.

Patch Changes

• #11716 f4057c1 Thanks @florian-lefebvre! - Fixes content types sync in dev

• #11645 849e4c6 Thanks @bluwy! - Refactors internally to use node:util parseArgs instead of yargs-parser

• #11712 791d809 Thanks @matthewp! - Fix mixed use of base + trailingSlash in Server Islands

• #11709 3d8ae76 Thanks @matthewp! - Fix adapter causing Netlify to break

Patch Changes

• #11645 849e4c6 Thanks @bluwy! - Refactors internally to use node:util parseArgs instead of arg