fix(content): generate anyOf schema for file() loader to support top-level arrays#16730
Conversation
…level arrays
The file() loader accepts both top-level array JSON files and record object
JSON files. Previously, generateJSONSchema always wrapped the item schema in
z.object({}).catchall() which produces a type:object JSON schema. When the
source file is a top-level array, VS Code reports validation errors because
the data shape doesn't match the generated schema.
Replace the object-only wrapping with a z.union of the array shape and the
object shape. This generates an anyOf in the output JSON schema, allowing
VS Code to validate array-shaped and object-shaped files correctly.
The $schema property is injected into the object branch only — top-level
array JSON files cannot reference an external schema property.
Fixes withastro#16602
🦋 Changeset detectedLatest commit: 91e5e41 The changes in this PR will be included in the next version bump. This PR includes changesets to release 416 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 |
There was a problem hiding this comment.
Pull request overview
This PR updates Astro’s content types generator to emit a JSON Schema for the built-in file() loader that validates both supported source shapes (top-level arrays and record objects). This addresses editor validation issues (e.g. VS Code) when the source JSON is an array but the generated schema previously described only an object/record shape.
Changes:
- Special-case
file-loaderschema generation to use a union ofarray(itemSchema)andobject-with-additionalProperties(record) schema branches. - Limit the “allow
$schemaproperty in data files” behavior to the object/record branch (since top-level arrays can’t include a$schemaproperty in the instance document).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ematipico
left a comment
There was a problem hiding this comment.
- restore PR our template and fill it
- add a test or explain your testing strategy
- add a changeset
As is, we can't accept this PR
|
Hi @ematipico! Addressed all three points:
Ready for re-review! |
| 'astro': patch | ||
| --- | ||
|
|
||
| fix(content): generate `anyOf` JSON Schema for `file()` loader to support top-level array JSON/YAML files |
There was a problem hiding this comment.
Please reword the changeset to follow our guides https://contribute.docs.astro.build/docs-for-code-changes/changesets/#tips-and-examples
…level arrays (#16730) * fix(content): generate anyOf schema for file() loader to support top-level arrays The file() loader accepts both top-level array JSON files and record object JSON files. Previously, generateJSONSchema always wrapped the item schema in z.object({}).catchall() which produces a type:object JSON schema. When the source file is a top-level array, VS Code reports validation errors because the data shape doesn't match the generated schema. Replace the object-only wrapping with a z.union of the array shape and the object shape. This generates an anyOf in the output JSON schema, allowing VS Code to validate array-shaped and object-shaped files correctly. The $schema property is injected into the object branch only — top-level array JSON files cannot reference an external schema property. Fixes #16602 * test: update content intellisense test for file loader union schema * chore: add changeset for file loader anyOf schema fix * docs(changeset): reword to user-facing prose per astro guide
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [astro](https://astro.build) ([source](https://github.com/withastro/astro/tree/HEAD/packages/astro)) | [`6.3.5` → `6.3.6`](https://renovatebot.com/diffs/npm/astro/6.3.5/6.3.6) |  |  | --- ### Release Notes <details> <summary>withastro/astro (astro)</summary> ### [`v6.3.6`](https://github.com/withastro/astro/blob/HEAD/packages/astro/CHANGELOG.md#636) [Compare Source](https://github.com/withastro/astro/compare/astro@6.3.5...astro@6.3.6) ##### Patch Changes - [#​16774](withastro/astro#16774) [`8f77583`](withastro/astro@8f77583) Thanks [@​astrobot-houston](https://github.com/astrobot-houston)! - Fixes markdown images with empty alt text (``) in content collections dropping the `alt` attribute entirely. The `alt=""` attribute is now correctly preserved in the rendered HTML output, which is important for accessibility (indicating decorative images). - [#​16776](withastro/astro#16776) [`3d10b5e`](withastro/astro@3d10b5e) Thanks [@​matthewp](https://github.com/matthewp)! - Fixes HMR serving stale content when components are passed as props via `getStaticPaths()` - [#​16784](withastro/astro#16784) [`7453860`](withastro/astro@7453860) Thanks [@​ematipico](https://github.com/ematipico)! - Improved the printing of the build time if it goes over the 60 seconds. - [#​16665](withastro/astro#16665) [`3dbbcee`](withastro/astro@3dbbcee) Thanks [@​Princesseuh](https://github.com/Princesseuh)! - Fixes remote SVG sources erroring with `dangerouslyProcessSVG` after the v6.3 SVG-processing gate. The default Sharp service now resolves the output format from the source up-front when it can (URL extension, `data:` MIME, ESM metadata), and from the actual buffer at request time when it can't, so SVG sources pass through untouched without needing to set `image.dangerouslyProcessSVG: true` or an explicit `format="svg"`. The error message has also been updated to point at `format="svg"` as the simpler workaround when an SVG source is encountered without `dangerouslyProcessSVG` enabled. - [#​16777](withastro/astro#16777) [`1754b91`](withastro/astro@1754b91) Thanks [@​matthewp](https://github.com/matthewp)! - Fixes HMR serving stale content for dynamically imported components through barrel files - [#​16730](withastro/astro#16730) [`068d924`](withastro/astro@068d924) Thanks [@​harshagarwalnyu](https://github.com/harshagarwalnyu)! - Fixes an issue where the `file()` content loader did not generate a valid JSON Schema for collections whose JSON or YAML data is a top-level array instead of an object. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xODIuMSIsInVwZGF0ZWRJblZlciI6IjQzLjE4Mi4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Changes
file()loader JSON Schema generation now emits ananyOfschema instead of a plain record-only schema{ type: 'array', items: <itemSchema> }— validates top-level array JSON/YAML files (e.g.[{ name: 'red', color: '#f00' }]){ type: 'object', additionalProperties: <itemSchema>, properties: { $schema: string } }— validates record-style files and preserves the$schemaproperty.changeset/tangy-chairs-smile.md)Testing
Updated
packages/astro/test/content-intellisense.test.ts— renamed and expanded the existing test to assert:schema.anyOfexists with exactly 2 branchestype: 'array'withitems.propertiesmatching the collection item schematype: 'object'withadditionalProperties.propertiesmatching the item schema and a$schemaproperty presentRun with:
pnpm test packages/astro/test/content-intellisense.test.tsDocs
No docs change needed — this is an internal schema generation improvement. The
file()loader public API is unchanged; users who already usefile()get correct IntelliSense automatically.