Typify generation is configurable, and in particular there are mechanisms (such as the replace imperative to the macro, or TypeSpaceSettings::with_replacement()) that cause types to be used from other crates rather than typify generating the type.
When types are generated, they are a translation of the schema into a type; when types are replaces, the full burden of ensuring equivalency or compatibility between the schema and type used falls to the consumer. If the supplied type is not compatible, there are a range of tricky to debug failures.
To help catch incompatibilities earlier, typify could generate test code that compares the JSON schema of the supplied type with the schema (i.e. the schema we don't use for type generation). This does assume that the supplied type implements JsonSchema... but that seems like it will often or typically be the case. It's important that failures of these generated tests are easy to comprehend and address. Since this is generated code, it would be easy to have unintelligible failures masked e.g. by a macro invocation. To that end, we'll probably want another crate in the typify ecosystem (typify-test?) that contains the explicit test code. The failures should make clear 1. the type being tested 2. the specific schema incompatibility and 3. the remediation (e.g. supply a compatible type or do generate the type).
Typify generation is configurable, and in particular there are mechanisms (such as the
replaceimperative to the macro, orTypeSpaceSettings::with_replacement()) that cause types to be used from other crates rather than typify generating the type.When types are generated, they are a translation of the schema into a type; when types are replaces, the full burden of ensuring equivalency or compatibility between the schema and type used falls to the consumer. If the supplied type is not compatible, there are a range of tricky to debug failures.
To help catch incompatibilities earlier, typify could generate test code that compares the JSON schema of the supplied type with the schema (i.e. the schema we don't use for type generation). This does assume that the supplied type implements
JsonSchema... but that seems like it will often or typically be the case. It's important that failures of these generated tests are easy to comprehend and address. Since this is generated code, it would be easy to have unintelligible failures masked e.g. by a macro invocation. To that end, we'll probably want another crate in the typify ecosystem (typify-test?) that contains the explicit test code. The failures should make clear 1. the type being tested 2. the specific schema incompatibility and 3. the remediation (e.g. supply a compatible type or do generate the type).