fix(content): add render() type overload for live collection entries#16699
fix(content): add render() type overload for live collection entries#16699rururux wants to merge 3 commits into
render() type overload for live collection entries#16699Conversation
🦋 Changeset detectedLatest commit: 1198235 The changes in this PR will be included in the next version bump. This PR includes changesets to release 435 packages
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 |
|
I'm not sure if this is actually the fix. As I'm seeing, the type astro/packages/astro/templates/content/types.d.ts Lines 122 to 124 in c0db63d The test here works. However, it doesn't work in the reproduction repo from the issue. The type astro/packages/astro/test/content-collections-type-inference.test.ts Lines 41 to 52 in c0db63d |
|
|
||
| // ref: https://github.com/withastro/astro/issues/16688 | ||
| it('astro check no errors', { | ||
| timeout: 35000, |
There was a problem hiding this comment.
we need to find another way to test this other than this. I don't know if we have any existing astro check tests we can base off of or not.
There was a problem hiding this comment.
Thanks for the review! The test I wrote was based on this file, would you prefer an approach that doesn't use astro check or tsc?
The challenge is that the astro:content types are generated at build time, which makes it difficult to write type-checking tests without using one of those CLI commands (which run after the build).
After investigating the generated type file, I found that the truly dynamic parts are only DataEntryMap and two typeof import(...) lines for ContentConfig and LiveContentConfig.
astro/packages/astro/templates/content/types.d.ts
Lines 122 to 124 in c0db63d
astro/packages/astro/templates/content/types.d.ts
Lines 152 to 153 in c0db63d
The
DataEntryMap is already covered by existing tests.If we separate the static and dynamic parts of the type template, we could test the
render() overload without a build at all.Happy to implement that if it's the preferred direction.
|
@Eptagone For example, The test you linked does validate So my understanding is that |
fixes: #16688
Changes
There was an issue where passing the
entryproperty, returned by thegetLiveEntryfunction imported fromastro:content, to therenderfunction caused a type error.This pull request adds tests and a changeset to the fix originally authored by Houston bot.
Houston bot comment:
Testing
Added a test using the
astro checkcommand to verify that no type errors occur.No changes were made to the test fixtures themselves. The error was originally occurring at the following location.
astro/packages/astro/test/fixtures/live-loaders/src/pages/rendered.astro
Lines 2 to 10 in c0db63d
Docs
N/A, bug fix