304823811e
* feat: respect `slug` frontmatter prop * chore: replace `slug` check with proper types * fix: regen types on `slug` change * chore: add TODO on slug gen * tests: update to use `slug` frontmatter prop * chore: add error message on `slug` inside object schema * lint * chore: add note on frontmatter parse * refactor: move content errors to new heading * chore: ContentSchemaContainsSlugError * chore: changeset * docs: be 10% less gentle Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca> * fix: avoid parsing slug on unlink * docs: clarify old API is for beta users Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
1.3 KiB
| astro |
|---|
| major |
Content collections: Introduce a new slug frontmatter field for overriding the generated slug. This replaces the previous slug() collection config option from Astro 1.X and the 2.0 beta.
When present in a Markdown or MDX file, this will override the generated slug for that entry.
# src/content/blog/post-1.md
---
title: Post 1
+ slug: post-1-custom-slug
---
Astro will respect this slug in the generated slug type and when using the getEntryBySlug() utility:
---
import { getEntryBySlug } from 'astro:content';
// Retrieve `src/content/blog/post-1.md` by slug with type safety
const post = await getEntryBySlug('blog', 'post-1-custom-slug');
---
Migration
If you relied on the slug() config option, you will need to move all custom slugs to slug frontmatter properties in each collection entry.
Additionally, Astro no longer allows slug as a collection schema property. This ensures Astro can manage the slug property for type generation and performance. Remove this property from your schema and any relevant slug() configuration:
const blog = defineCollection({
schema: z.object({
- slug: z.string().optional(),
}),
- slug({ defaultSlug, data }) {
- return data.slug ?? defaultSlug;
- },
})