Using Typebox validator on non-Typebox JSON schema

[yacinehmito]

On some part of my app, I have some JSON schemas coming from configuration code, so it cannot be turned into Typebox constructs. I still want to validate data against those schemas (knowing I will not get type inference).
From what I understand, Parse is only compatible with objects built with Typebox, so I'd have to include another validator to the project just for these types.

Is my assumption correct? If so, which constraint makes validation only available to schemas built with Typebox?

[sinclairzx81]

Hi,

---

On some part of my app, I have some JSON schemas coming from configuration code, so it cannot be turned into Typebox constructs. I still want to validate data against those schemas (knowing I will not get type inference).

It is actually possible to convert raw schematics into TypeBox types. Have a look at the following URL + Example

https://github.com/sinclairzx81/typebox/blob/master/example/prototypes/from-schema.ts

import { FromSchema } from './prototypes/from-schema'

const T = FromSchema({ 
  type: 'object',
  required: ['x', 'y', 'z'],
  properties: {
    x: { type: 'number' },
    y: { type: 'number' },
    z: { type: 'number' },
  }
} as const) // or 'as unknown' if the schematics originate from elsewhere

console.log(T)

The FromSchema type is currently treated as an extension / prototype for now.

---

... which constraint makes validation only available to schemas built with Typebox?

The primary constraint is that TypeBox requires specific symbols to be applied appropriately to schematics. TypeBox validators operate almost exclusively by introspecting Kind, Hint, Modifier, and Transform descriptor symbols applied to schematics. As a result, remote schematics require a loading phase to apply these symbols correctly (as shown in the FromSchema example above).

There's a couple of reasons for this design ....

1. Ambiguity resolution: Symbol descriptors help differentiate between ambiguous schematics. For example, the schema {} could represent either any or unknown. In addition, symbols serve as a contract for a schematic, ensuring that an Object symbol means the schematic conforms to the object representation mandated by TypeBox. This mostly prevents ambiguity if users were to attempt to mix different schema vocabularies.
2. Performance optimizations: Symbols accelerate schema introspection and compilation. Instead of introspecting each property of a schema individually to learn what the schema is representing, TypeBox can inspect a single symbol descriptor to determine the schema's exact structure. This helps to speed up application start times when running TypeBox JIT on certain cloud infrastructure.
3. Support for multiple schema representations: Symbols enable TypeBox to potentially support different schema representations under a common named descriptor. For example, Tuple structures are represented differently in Draft 7 and Draft 2020-12 but most users probably don't care about the representation, only that a type is Tuple. Having a named descriptor for tuple-like schematics captures structural intent, but permits flexibility in representation (including for entirely different specifications, such as Json Type Definition)

In short, the reason schematics can't be loaded directly is because they need to be normalized to the subset of schematics supported by TypeBox then have symbols applied accordingly.

---

Hope this brings some insight. From your query, If you need to load remote schematics, consider the FromSchema function. Alternatively, Ajv is still a really good option for validation.

I will say though. The symbol requirement for schematics was devised several years ago to work through some fairly difficult alignment issues between TypeScript and Json Schema, but I've not been entirely happy with the design (mostly because it makes loading remote schematics more difficult than it needs to be). I will be reviewing the implementation at some point, and I think there may be some alternative approaches to schema differentiation that could make removing symbols more feasible. Something for down the road tho.

Happy to discuss more if you have any questions
Cheers
S

[yacinehmito]

Thank you very much for this thorough answer!