fix: include undefined in types for getEntry with content layer

[ascorbic]

Changes

Currently the types for getEntry exclude undefined if the key passed is a key in the type. This works for the old system where there were types for every entry, but now they are types as Record<string, {//...the type }>, it means any key will match (because they're all strings), meaning the entries are incorrectly returned as not nullable. This PR changes this so that if the key type is string (i.e. the type does not have specific entries), then the return type is nullable.

This is technically a breaking change but I think we can slip it in in 5.0.x

Fixes #12598

Testing

Docs

Our migration guide already says that the types for getEntry have been loosened.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3546e72

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

[HiDeoo]

Tested locally against the repro in #12598 and this now works as expected:

🙌

[delucis]

LGTM — thanks @ascorbic!

[Nickersoft]

Just ran into this myself using Content Collections – I think it might be worth updating the docs, as the way they're currently written imply that you don't need any null/undefined checks when using getEntry:

https://docs.astro.build/en/guides/content-collections/#rendering-body-content

Also, what is the proper way to perform these checks? Right now I'm just using a not-null assertion when passing it into render().

[ascorbic]

You can pass null entries to render(): it will render an empty component. I think the answer is to ensure the types allow that. But the correct way to handle it is probably to do something like render a 404 if it's not found.