Frontmatter data stripped off from collection entry data

[jurajkapsz]

Astro Info

Astro                    v5.0.0-beta.7
Node                     v20.11.1
System                   Linux (x64)
Package Manager          pnpm
Output                   static
Adapter                  @astrojs/node
Integrations             @astrojs/mdx
                         build/images
                         build/cleanup
                         @astrojs/sitemap

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

No response

Describe the Bug

Frontmatter properties, that aren't defined via zod schema in content collection config.ts, do not appear in returned collection entry data object. Probably a feature, but haven't read about it in docs and was surprised a bit by it, so I'm filing a report just in case.

config.ts

...
const collection = defineCollection({
  loader... // glob
  schema: z.object({
    title: z.string()
  })
});
...

collection md file entry

---
title: Lorem ipsum dolor sit amet
someData: Sed eget massa ultrices
---

Aliquam ac ullamcorper nisi. Aliquam quis porta risus. Proin sed tincidunt eros, nec placerat felis.

astro template

...
const entry = await getEntry("collection", "entry");

console.log(entry.data); // --> { title: "Lorem ipsum dolor sit amet" }, no "someData" prop :O

What's the expected result?

If it's a bug
All existing frontmatter data should be included in the collection entry data object, ie following the example above:

...
const entry = await getEntry("collection", "entry");

console.log(entry.data);
// { title: "Lorem ipsum dolor sit amet", someData: "Sed eget massa ultrices" }

If it's a feature
There should be a terminal log about this intervention.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-fggxst?file=src%2Fcontent%2Fconfig.ts,src%2Fpages%2Findex.astro,src%2Fdata%2Fcoll%2Fone.md

Participation

• I am willing to submit a pull request for this issue.

[jurajkapsz]

Update

Probably this doc info implies the mentioned behavior of stripping off data properties that are not declared in schema:

Every frontmatter or data property of your collection entries must be defined using a Zod data type...

When there is no collection schema defined, all frontmatter data is included in collection entry data as expected.

Wondering though, if a log message regarding the stripped data would be useful, or some explicit mentioning of it in docs; but maybe its just me.

[ematipico]

It seems that a docs PR was raised. I am going to close this issue

[jurajkapsz]

@ematipico I'd like to ask, because I don't have experiences with this and I didn't get a feedback about a behavior I think might be potentially a bug:

So it is a designed behavior for collection schema that when I get some data from loader with a shape of eg four properties, but in collection (zod) schema I describe only three (eg. due to oversight), the later on provided collection entry data will have only those three data properties? So the collection schema works also as a filter to my whatever data, not just as a typescript typeset, is that correct?

I'd expect, that I should filter my data during API request time and that I should be warned if some data would be somehow auto-excluded from the returned collection entry data, in this case because of defined collection schema.

I do apologize, I don't have an opinion about this, I only try to get a hang of it how it works :)

[sarah11918]

I know this issue is closed, and we're discussing in a docs PR but I'm not entirely sure whether this is something to document. And the latest question here makes it sound like a question re: whether it's possible to surface an error:

I'd expect, that I should filter my data during API request time and that I should be warned if some data would be somehow auto-excluded from the returned collection entry data, in this case because of defined collection schema.

So quick re-open here just to check:

@ascorbic Is there some way for the loader to know/evaluate whether the loaded data in fact does match the schema vs silently only processing what it's been asked for in order to surface an error?

It seems in this case, (if I understand correctly), Juraj didn't fully define all properties as an oversight (not looking for some intentional behaviour re: only defining some properties of the data). So I don't think it's really a documentation issue since we do already say clearly "define everything in your schema!" and this doesn't seem to be a request to further explain some fancier use case re: ignoring some of your data. It seems instead explanation of what went wrong in the case of, by mistake, not following what the docs currently say. 😄

It seems like what happened here is not a docs issue, but an expectation of what happens in the case of an error. Is the information known to Astro at the right time in order to provide such an error? I think this might be a better path than a line in docs, in the case that someone's loaded data doesn't match their schema. Just wondering whether that's possible!

I think when this becomes something for docs is if we do explicitly want to call attention to a use case like, "Hey, if you only want to import some of the properties to make your collection, just define the ones you want in your schema!" But this certainly won't be the expected case, and I would assume people are free to just ignore those properties in their Astro project if they don't want to use them? This doesn't sound like the happy path to me, but if there are common/legitimate use cases for this and we decide it's helpful to show them, then I think that's when we change docs.

Otherwise, I think telling people they have to define every property in their schema is what docs should be doing.