fix: loosen the BaseSchema type #13734
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
Previously
BaseSchemaused recursive type definitions to try to define "any Zod object, or wrapper type that contains objects". This contained self-referencing types that collapsed toany, meaning there was no typechecking for schema defintions. #13706 fixed that by refactoring out the self-references. However this caused Starlight typechecks to fail (and presumably other sites). At its core, this is because Zod types are inherently recursive, so it's impossible to accurately type them without using recursive types, unless you manually define an arbitrary number of depth of reference. There will always be another layer of abstraction that some user (or more likely integration or library) wants to create.This PR throws it all away, and simply types
BaseSchemaasZodType. This is wider than we actually want: it accepts primitives other than objects. However, so doesany, so this is an improvement over that.Fixes #13713
Testing
The Starlight typecheck that was failing in ecosystem-ci is now passing.
Docs