fix: don't strip "slug" from content layer data

[ascorbic]

Changes

The backward compat changes had introduced a bug, where content layer collections were having their slug field stripped. This PR fixes it so it only happens for legacy collections. This bug is not present in main.

Fixes #12162

Testing

Added a test

Docs

[changeset-bot]

🦋 Changeset detected

Latest commit: 0a16aa8

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ematipico]

Some tests are failing 😢

[datner]

🎉

[jurajkapsz]

Will this land also in Astro v4? The same issue there when using content layer <3

[ematipico]

Will this land also in Astro v4? The same issue there when using content layer <3

No, because the issue was filed against Astro v5

[ascorbic]

I couldn't reproduce this on main when I was testing it, so I made it against v5.

[jurajkapsz]

I couldn't reproduce this on main when I was testing it, so I made it against v5.

Thank you @ascorbic . I'll create a new issue with a reproduction, because I don't know if it is the exact same issue, as it concerns using slug in frontmatter.

[jurajkapsz]

I couldn't reproduce this on main when I was testing it, so I made it against v5.

I apologize, @ascorbic you are correct , in Astro v4 this is fine. Edit: I had to change the way I access the slug field, as it is now [with content layer] in the data object as a common frontmatter field.

One thing surprised me though, that a "slug"-named frontmatter field still modifies collection entry id value in Content Layer, as it was in legacy content collections. But I easily overrode this behavior with glob loader's generateId function, in my case to basically restore the entry id value provided by default, and have my slug value as well. Don't know if this is an issue, or a backwards compatibility feature, but the generateId works fine.