Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reference from astro:content no-longer validates entries exist #13268

Open
1 task
KianNH opened this issue Feb 19, 2025 · 1 comment
Open
1 task

reference from astro:content no-longer validates entries exist #13268

KianNH opened this issue Feb 19, 2025 · 1 comment
Labels
- P2: nice to have Not breaking anything but nice to have (priority) feat: content layer Related to the Content Layer feature (scope) requires refactor Bug, may take longer as fixing either requires refactors, breaking changes, or considering tradeoffs

Comments

@KianNH
Copy link

KianNH commented Feb 19, 2025

Astro Info

Astro                    v5.3.0
Node                     v18.20.3
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             @astrojs/starlight

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The reference helper from astro:content: allows you to validate frontmatter against another collection:

The reference() function is used in the content config to define a relationship, or “reference,” from one collection to another. This accepts a collection name and validates the entry identifier(s) specified in your content frontmatter or data file.

In Astro 4, when provided with an identifier that does not exist in the referenced collection, an error would be thrown:

14:03:17 [ERROR] [InvalidContentEntryFrontmatterError] docs → index.mdx frontmatter does not match collection schema.
authors.1: Reference to authors invalid. Entry foo does not exist.

In Astro 5, the entries are accepted and would only fail at the time when getEntry/getEntries is used and undefined is returned.

For example, when using JSON.stringify on the data of an entry and the result of getEntries(data.authors) in the reproduction:

{
  "title": "Welcome to Starlight",
  "description": "Get started building your docs site with Starlight.",
  "editUrl": true,
  "head": [],
  "template": "splash",
  "sidebar": {
    "hidden": false,
    "attrs": {}
  },
  "pagefind": true,
  "draft": false,
  "authors": [
    {
      "id": "john",
      "collection": "authors"
    },
    {
      "id": "foo",
      "collection": "authors"
    }
  ]
}
[
  {
    "id": "john",
    "data": {
      "name": "john"
    },
    "filePath": "src/content/authors/john.yaml",
    "digest": "70ef204af8501704",
    "collection": "authors"
  },
  null
]

What's the expected result?

Invalid entries are validated when the frontmatter is parsed or the documentation is amended to say that validation should be done by the author in the areas they are using the frontmatter.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-rm62ioqd

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label Feb 19, 2025
@florian-lefebvre
Copy link
Member

You can look at #12990 for some context. I think ideally we want to make it behave more like v4 but this will be a breaking change

@florian-lefebvre florian-lefebvre added - P2: nice to have Not breaking anything but nice to have (priority) requires refactor Bug, may take longer as fixing either requires refactors, breaking changes, or considering tradeoffs feat: content layer Related to the Content Layer feature (scope) and removed needs triage Issue needs to be triaged labels Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- P2: nice to have Not breaking anything but nice to have (priority) feat: content layer Related to the Content Layer feature (scope) requires refactor Bug, may take longer as fixing either requires refactors, breaking changes, or considering tradeoffs
Projects
None yet
Development

No branches or pull requests

2 participants