Conversation
apoco
commented
Jul 15, 2023
apoco
commented
- List specific formats supported by ajv
- Fix security vulnerabilities
- Fix random typos
- List specific formats supported by ajv - Fix security vulnerabilities - Fix random typos
|
Awesome, thanks! If you're using this in production, one thing to note is that I'm not actively maintaining this library (though I'm very happy to review PRs) and there may be better alternatives using more recent Typescript features. The problem with using this library in production is that it creates insanely complicated types that substantially slow down compilation. That said, thanks for the fix, and I'll try to find some time to make some more improvements here soon! |
| "@typescript-eslint/eslint-plugin": "^6.0.0", | ||
| "@typescript-eslint/eslint-plugin-tslint": "^6.0.0", | ||
| "@typescript-eslint/parser": "^6.0.0", |
| // PARTIALLY ENFORCED (🔓) indicates that the field is partially enforced by the type system, but it may be possible | ||
| // to assign a type to T that fails validation against s. | ||
| // For example, arrays with the additionalItems parameter are PARTIALLY ENFORCED becuase (currently) every element in | ||
| // For example, arrays with the additionalItems parameter are PARTIALLY ENFORCED because (currently) every element in |
| enum?: Enum; // 💪 | ||
| type?: Type; // 💪 | ||
| format?: Type extends "string" ? string : never; // ⚠️ only makes sense for string types | ||
| format?: Type extends "string" |
There was a problem hiding this comment.
Can you add a comment referencing where these come from? Assuming this is in the spec, lgtm
There was a problem hiding this comment.
I can add later on in my alt account, good call. It's actually not from the spec but from ajv; they don't have a type exposing their default supported formats, unfortunately.
There was a problem hiding this comment.
That's fine; since we're using ajv under the hood let's just point to wherever it's being implemented.
Well it's been quite useful so far. I have a similar never-released code base that does something quite similar, and I know how complicated it can get (and mine was before conditional types were released!). I never figured out how to do references and abandoned the effort. Know of any alternatives that fill this niche that you'd recommend (short of code generation)? I might use |
Code generation is often a pretty good bet. It can get complicated with json schema but I've had a lot of success with json type definition (https://jsontypedef.com/) If code generation is out of the question, I have to imagine Zod would work! This project would also definitely work for a small codebase, I just caution you that as it grows you may start running into compiler OOMs. |
|
@apoco mind if I make the requested change and pull this in/cut a release? |
|
Sure, that would be much appreciated, thank you.
…On Tue, Jul 25, 2023 at 5:58 PM Robbie Ostrow ***@***.***> wrote:
@apoco <https://github.com/apoco> mind if I make the requested change and
pull this in/cut a release?
—
Reply to this email directly, view it on GitHub
<#61 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGTFF7ZGZN2V2CKXWUIVTXSBTSHANCNFSM6AAAAAA2LPHPKE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
For my own reference for this weekend, this is actually part of the spec (at least the latest version!) https://json-schema.org/draft/2020-12/json-schema-validation.html#name-defined-formats I have to read the spec more carefully to determine whether limiting this is actually correct; seems like custom implementations can define their own formats |
3 participants
