[email protected]

Major Changes

• #11979 423dfc1 Thanks @bluwy! - Bumps vite dependency to v6.0.0-beta.2. The version is pinned and will be updated as new Vite versions publish to prevent unhandled breaking changes. For the full list of Vite-specific changes, see its changelog.

• #12100 abf9a89 Thanks @astrobot-houston! - Refactors legacy content and data collections to use the Content Layer API glob() loader for better performance and to support backwards compatibility. Also introduces the legacy.collections flag for projects that are unable to update to the new behavior immediately.

  ⚠️ BREAKING CHANGE FOR LEGACY CONTENT COLLECTIONS ⚠️

  By default, collections that use the old types (content or data) and do not define a loader are now implemented under the hood using the Content Layer API's built-in glob() loader, with extra backward-compatibility handling.

  In order to achieve backwards compatibility with existing content collections, the following have been implemented:

  • a glob loader collection is defined, with patterns that match the previous handling (matches src/content/<collection name>/**/*.md and other content extensions depending on installed integrations, with underscore-prefixed files and folders ignored)
  • When used in the runtime, the entries have an ID based on the filename in the same format as legacy collections
  • A slug field is added with the same format as before
  • A render() method is added to the entry, so they can be called using entry.render()
  • getEntryBySlug is supported

  In order to achieve backwards compatibility with existing data collections, the following have been implemented:

  • a glob loader collection is defined, with patterns that match the previous handling (matches src/content/<collection name>/**/*{.json,.yaml} and other data extensions, with underscore-prefixed files and folders ignored)
  • Entries have an ID that is not slugified
  • getDataEntryById is supported

  While this backwards compatibility implementation is able to emulate most of the features of legacy collections, there are some differences and limitations that may cause breaking changes to existing collections:

  • In previous versions of Astro, collections would be generated for all folders in src/content/, even if they were not defined in src/content/config.ts. This behavior is now deprecated, and collections should always be defined in src/content/config.ts. For existing collections, these can just be empty declarations (e.g. const blog = defineCollection({})) and Astro will implicitly define your legacy collection for you in a way that is compatible with the new loading behavior.
  • The special layout field is not supported in Markdown collection entries. This property is intended only for standalone page files located in src/pages/ and not likely to be in your collection entries. However, if you were using this property, you must now create dynamic routes that include your page styling.
  • Sort order of generated collections is non-deterministic and platform-dependent. This means that if you are calling getCollection(), the order in which entries are returned may be different than before. If you need a specific order, you should sort the collection entries yourself.
  • image().refine() is not supported. If you need to validate the properties of an image you will need to do this at runtime in your page or component.
  • the key argument of getEntry(collection, key) is typed as string, rather than having types for every entry.

  A new legacy configuration flag legacy.collections is added for users that want to keep their current legacy (content and data) collections behavior (available in Astro v2 - v4), or who are not yet ready to update their projects:

  // astro.config.mjs
  import { defineConfig } from 'astro/config';
  
  export default defineConfig({
    legacy: {
      collections: true,
    },
  });

  When set, no changes to your existing collections are necessary, and the restrictions on storing both new and old collections continue to exist: legacy collections (only) must continue to remain in src/content/, while new collections using a loader from the Content Layer API are forbidden in that folder.

• #12079 7febf1f Thanks @ematipico! - params passed in getStaticPaths are no longer automatically decoded.

  [changed]: params aren't decoded anymore.

  In Astro v4.x, params in were automatically decoded using decodeURIComponent.

  Astro v5.0 doesn't automatically decode params in getStaticPaths anymore, so you'll need to manually decode them yourself if needed

  What should I do?

  If you were relying on the automatic decode, you'll need to manually decode it using decodeURI.

  Note that the use of decodeURIComponent) is discouraged for getStaticPaths because it decodes more characters than it should, for example /, ?, # and more.

  ---
  export function getStaticPaths() {
    return [
  +    { params: { id: decodeURI("%5Bpage%5D") } },
  -    { params: { id: "%5Bpage%5D" } },
    ]
  }
  
  const { id } = Astro.params;
  ---

Patch Changes

• #12127 55e9cd8 Thanks @ascorbic! - Prevents Vite emitting an error when restarting itself

@astrojs/[email protected]

Patch Changes

• #12102 dcc1e89 Thanks @hermit99! - Fixes an Reference Error that occurred during client transitions

[email protected]

Patch Changes

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

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

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

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

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

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

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

@astrojs/[email protected]

Minor Changes

• #11485 fbe1bc5 Thanks @sondr3! - Adds new xslURL option to enable styling of sitemaps

[email protected]

Patch Changes

• #12084 12dae50 Thanks @Princesseuh! - Adds missing filePath property on content layer entries

• #12046 d7779df Thanks @martrapp! - View transitions: Fixes Astro's fade animation to prevent flashing during morph transitions.

• #12043 1720c5b Thanks @bluwy! - Fixes injected endpoint prerender option detection

• #12095 76c5fbd Thanks @TheOtterlord! - Fix installing non-stable versions of integrations with astro add

[email protected]

Minor Changes

• #12047 21b5e80 Thanks @rgodha24! - Adds a new optional parser property to the built-in file() loader for content collections to support additional file types such as toml and csv.

  The file() loader now accepts a second argument that defines a parser function. This allows you to specify a custom parser (e.g. toml.parse or csv-parse) to create a collection from a file's contents. The file() loader will automatically detect and parse JSON and YAML files (based on their file extension) with no need for a parser.

  This works with any type of custom file formats including csv and toml. The following example defines a content collection dogs using a .toml file.

  [[dogs]]
  id = "..."
  age = "..."
  
  [[dogs]]
  id = "..."
  age = "..."

  After importing TOML's parser, you can load the dogs collection into your project by passing both a file path and parser to the file() loader.

  import { defineCollection } from "astro:content"
  import { file } from "astro/loaders"
  import { parse as parseToml } from "toml"
  
  const dogs = defineCollection({
    loader: file("src/data/dogs.toml", { parser: (text) => parseToml(text).dogs }),
    schema: /* ... */
  })
  
  // it also works with CSVs!
  import { parse as parseCsv } from "csv-parse/sync";
  
  const cats = defineCollection({
    loader: file("src/data/cats.csv", { parser: (text) => parseCsv(text, { columns: true, skipEmptyLines: true })})
  });

  The parser argument also allows you to load a single collection from a nested JSON document. For example, this JSON file contains multiple collections:

  { "dogs": [{}], "cats": [{}] }

  You can seperate these collections by passing a custom parser to the file() loader like so:

  const dogs = defineCollection({
    loader: file('src/data/pets.json', { parser: (text) => JSON.parse(text).dogs }),
  });
  const cats = defineCollection({
    loader: file('src/data/pets.json', { parser: (text) => JSON.parse(text).cats }),
  });

  And it continues to work with maps of id to data

  bubbles:
    breed: 'Goldfish'
    age: 2
  finn:
    breed: 'Betta'
    age: 1

  const fish = defineCollection({
    loader: file('src/data/fish.yaml'),
    schema: z.object({ breed: z.string(), age: z.number() }),
  });

• #12071 61d248e Thanks @Princesseuh! - astro add no longer automatically sets output: 'server'. Since the default value of output now allows for server-rendered pages, it no longer makes sense to default to full server builds when you add an adapter

• #11963 0a1036e Thanks @florian-lefebvre! - Adds a new createCodegenDir() function to the astro:config:setup hook in the Integrations API

  In 4.14, we introduced the injectTypes utility on the astro:config:done hook. It can create .d.ts files and make their types available to user's projects automatically. Under the hood, it creates a file in <root>/.astro/integrations/<normalized_integration_name>.

  While the .astro directory has always been the preferred place to write code generated files, it has also been prone to mistakes. For example, you can write a .astro/types.d.ts file, breaking Astro types. Or you can create a file that overrides a file created by another integration.

  In this release, <root>/.astro/integrations/<normalized_integration_name> can now be retrieved in the astro:config:setup hook by calling createCodegenDir(). It allows you to have a dedicated folder, avoiding conflicts with another integration or Astro itself. This directory is created by calling this function so it's safe to write files to it directly:

  import { writeFileSync } from 'node:fs';
  
  const integration = {
    name: 'my-integration',
    hooks: {
      'astro:config:setup': ({ createCodegenDir }) => {
        const codegenDir = createCodegenDir();
        writeFileSync(new URL('cache.json', codegenDir), '{}', 'utf-8');
      },
    },
  };

• #12081 8679954 Thanks @florian-lefebvre! - Removes the experimental contentCollectionsCache introduced in 3.5.0.

  Astro Content Layer API independently solves some of the caching and performance issues with legacy content collections that this strategy attempted to address. This feature has been replaced with continued work on improvements to the content layer. If you were using this experimental feature, you must now remove the flag from your Astro config as it no longer exists:

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

  The cacheManifest boolean argument is no longer passed to the astro:build:done integration hook:

  const integration = {
      name: "my-integration",
      hooks: {
          "astro:build:done": ({
  -            cacheManifest,
              logger
          }) => {}
      }
  }

Patch Changes

• #12073 acf264d Thanks @bluwy! - Replaces ora with yocto-spinner

• #12075 a19530e Thanks @bluwy! - Parses frontmatter ourselves

• #12070 9693ad4 Thanks @ematipico! - Fixes an issue where the check origin middleware was incorrectly injected when the build output was "static"

• Updated dependencies [a19530e]:

  • @astrojs/[email protected]

@astrojs/[email protected]

Patch Changes

• #12073 acf264d Thanks @bluwy! - Replaces ora with yocto-spinner

@astrojs/[email protected]

Patch Changes

• #12075 a19530e Thanks @bluwy! - Parses frontmatter ourselves

• Updated dependencies [a19530e]:

  • @astrojs/[email protected]

@astrojs/[email protected]

Patch Changes

• #12075 a19530e Thanks @bluwy! - Parses frontmatter ourselves

@astrojs/[email protected]

Patch Changes

• #12075 a19530e Thanks @bluwy! - Parses frontmatter ourselves

• Updated dependencies [a19530e]:

  • @astrojs/[email protected]