Repository navigation
refactor(web_core_v1_0): build catalog JSON Schema in core - #14
Closed
louis-bompart wants to merge 3 commits into
Closed
louis-bompart wants to merge 3 commits into
louis-bompart wants to merge 3 commits into
Conversation
Assembling a catalog document and bundling its validation schema is JSON work: `$ref` handling, peer catalogs, common type bundling, unions and the protocol's rules about function arguments. It lived in @a2ui/schema-zod, so every other schema adapter would have had to rewrite it. It now lives in core: - catalog_document.ts: the document model, `toJson` and `retainedDefs` - validation_schema.ts: `validationSchema` and `cleanSchemaNode` - catalog_refs.ts: `$ref` resolution across a document and its peers, with `hasCrossDocumentRefs` - json_schema_rules.ts: standard definitions by protocol version, and `schemaRequiresArgs` - entry_definitions.ts: the definitions JSON-loaded entries came from An adapter now only converts one schema (`toJsonSchema`). It may also reproduce definitions its models record exactly (`reproduceDefinitions`, the Zod 3 `spec()` models), and name the descriptions its common type mirrors carry (`commonTypeRefDescriptions`). `serializeCatalog`, `generateValidationSchema`, `retainedDefs`, `schemaToJson` and `cleanSchemaNode` leave the contract. A catalog that carries its published document builds its model from that document, so its `validationSchema` needs no conversion at all. @a2ui/schema-zod keeps the Zod 3 parts: the conversion, the `spec()` shaper and the JSON-to-Zod loader. Its 260 tests pass unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Zod 4 adapter implements `toJsonSchema` with `z.toJSONSchema`, describing the values a payload may carry (`io: 'input'`), and names the descriptions its common type mirrors carry. Core then writes `toJson`, `validationSchema` and inline catalogs for Zod 4 catalogs defined in code. The `REF:` descriptions of the common types survive the conversion, so they come out as references to common_types.json. A test checks that the Zod 4 and Zod 3 adapters write the same `toJson` and `validationSchema` for the same catalog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The basic catalog carries its published document, from which core now builds `validationSchema` without converting any schema. The generator writes each function's `description` whether or not it reproduces the document; it is part of the function's API, and the validation schema reads it. A test checks that the validation schema equals the one the Zod 3 adapter builds from the published document, apart from the theme: the document declares none, and the catalog adds its own `BasicCatalogThemeSchema`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
The basic catalog gets
validationSchemaback, and Zod 4 catalogs defined in code gettoJson,validationSchemaand inline catalogs. To avoid writing the JSON Schema code a second time for Zod 4, this PR moves the library-neutral part of it from @a2ui/schema-zod into core.What moves into core
Five new modules in
@a2ui/web_core_v1_0/src/catalog/, about 1,500 lines. The JSON parts came from @a2ui/schema-zod'sschema_serializer.ts,schema_generator.ts,schema_loader.tsandspec_shape.ts.catalog_document.tstoJson,retainedDefsand the unionsvalidation_schema.tsvalidationSchemaandcleanSchemaNodecatalog_refs.ts$refresolution across a document and its peers, andhasCrossDocumentRefsjson_schema_rules.tsschemaRequiresArgsentry_definitions.tsAdapter contract
toJsonSchema(schema)REF:description pointers stay in, and core turns them into$refs.reproduceDefinitions(catalog)spec()models use it.commonTypeRefDescriptionsserializeCatalog,generateValidationSchema,retainedDefsschemaToJson,cleanSchemaNodeMessageProcessorcalled for legacy inline catalogs; it now usestoJsonSchemaand core'scleanSchemaNode.A catalog that carries its published document (
CatalogOptions.document, from #13) builds its model from that document, so it needs no schema conversion. This is how the basic catalog getsvalidationSchemaback.Commits
refactor(web_core_v1_0): build catalog JSON Schema in core. This is the move. @a2ui/schema-zod keeps only the Zod 3 parts: the conversion, thespec()shaper (now behindreproduceDefinitions) and the JSON-to-Zod loader, which imports the shared$refhandling from core. The 260 @a2ui/schema-zod tests pass unchanged. They include the integration tests that moved there in refactor(web_core_v1_0): pass schema adapters explicitly #10, such as peer catalogs, serialization and validation schemas.feat(schema-zod-v4): convert Zod 4 schemas to JSON Schema.toJsonSchemais built onz.toJSONSchemawithio: 'input'. A test checks that the Zod 4 and Zod 3 adapters produce identicaltoJsonandvalidationSchemafor the same catalog.feat(catalog-basic): restore validationSchema on Zod 4.descriptioneven when it isn't reproducing the document. A function description is part of its API, and the validation schema reads it.basicCatalog.validationSchemaequals what the Zod 3 adapter builds from the published document, except for$defs.theme. The published document declares no theme; the catalog adds its ownBasicCatalogThemeSchema, as it did on Zod 3.Things to review
inlinePeerAndLocalRefs,PeerScope,resolveJsonPointer,buildComponentUnion,setLoadedDefinition,standardDefsForVersionand others. That's the cost of letting any adapter reuse them.inlinePeerAndLocalRefs. Core exports it instead. Nothing in the repository imported it from @a2ui/schema-zod.MIRROR_REF_DESCRIPTIONSbecame an adapter member rather than being computed from core's standard definitions. Two of the 18 mirror descriptions (DynamicBoolean,Surface) differ from the standard text, so computing them in core would have changed the output.Validation
Each commit was built from clean, then linted, format-checked and tested. The first commit was also tested with
schema-zod-v4andcatalog-basicas they are on #13: 13/13 and 102/102. Lint has no errors.@a2ui/web_core_v1_0@a2ui/schema-zod@a2ui/schema-zod-v4@a2ui/catalog-basic🤖 Generated with Claude Code