Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better pre-validation errors for invalid TypeBox schema #812

Closed
aleclarson opened this issue Mar 25, 2024 · 2 comments
Closed

Better pre-validation errors for invalid TypeBox schema #812

aleclarson opened this issue Mar 25, 2024 · 2 comments

Comments

@aleclarson
Copy link

I wrote up a TypeBox schema for validating TypeBox schemas (very meta, much wow). This allows the type compiler to report useful errors when an invalid TypeBox schema is found.

alloc@91f0187#diff-7d17a75199d310e0589b29caf737356a21efdafb0dcb373c1543722f35cd96a8R84

Would you be interested in a PR with this commit?

@sinclairzx81
Copy link
Owner

@aleclarson Hi! :) Hey, this is super cool!

I really like this type and can definitely see it being useful for safely transferring schematics across the wire. At this stage though, I don't think I can introduce it as a standard type today, but can work towards introducing it in future (there would need to be work done elsewhere before introducing it). I do think though that this type aligns well with future plans for the library.

So, all new types usually go through a vetting phase before introduction into the library. It would be cool if you can include the Schema type here which means it will get maintained into the future.

https://github.com/sinclairzx81/typebox/tree/master/example/prototypes

In terms of the work that would need to be done to introduce the type. I have been considering trying to remove the [Kind], [Hint], [Optional], [Readonly] and [Recursive] symbols used for composition and differentiation of schematics at runtime (and statically). These symbols are non-serializable which means TB types cannot be transferred "in full" over a network. Because of this, introducing the Schema() type now would have an expectation that users "could" transfer TB schematics for remote validation (via the Compiler and Value modules). As this currently isn't the case, this aspect is a bit of a blocker.

This said, I am very interested in supporting this type "somehow". If you could submit a PR to the /examples/prototypes, will continue to maintain this type into the future, with it's inclusion happening in tandem with the removal of these Symbol properties.

Awesome work!
S

@sinclairzx81
Copy link
Owner

@aleclarson Hi,

Heya, will close off this issue for now, but can re-open at a later time. Happy to review a prototype PR for this as couple of people have asked about this functionality recently, having a reference implementation would be quite helpful :)

Cheers!
S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants