Support for draft-06

[azaslavsky]

The official draft-06 of JSON Schema is out. Given the scope of what's describable in Typescript, I think the changes needed to support it would be fairly minor (just const, empty required arrays, and boolean schemas as far as I can tell from a quick glance).

[azaslavsky]

Oops, realized it might be helpful to leave a link: http://json-schema.org/draft-06/json-schema-migration-faq.html

[victorandree]

I think this looks like a worthwhile thing to do. Going over the table, here's what I see should be done. Maybe I'll submit a PR for some of these items?

bold changes require code updates, italic require doc changes (to express that this is not expressible in TS).

change	consequence
"id" replaced by "$id"	should still support "id" for schema naming
"$id" replaces "id"	should support (prefer over "id") for schema naming
"$ref" only allowed where a schema is expected	no effect
"exclusiveMinimum" and "exclusiveMaximum"	not expressible in TS
booleans as schemas allowable anywhere	need to handle booleans in more places
"propertyNames" added	not expressible in TS (?)
"contains" added	not expressible in TS (?)
"const" added	should work like a single-member enum (named or not)
"required" allows an empty array	already supported
"dependencies" allows an empty array	not expressible in TS
"format": "uri-reference" added	not expressible in TS
"format": "uri-template" added	not expressible in TS
"format": "json-pointer" added	not expressible in TS
"examples" added	could be added to generated docstrings

Of course, now draft-07 is out. Some thoughts on this:

• $comment could be used like description to generate documentation but ... maybe not (i.e. leave it for schema maintainers).
• if/then/else: could these be used in interesting ways together with conditional types (coming in TypeScript 2.8)?
• readOnly could obviously be like readonly properties in TypeScript.
• writeOnly cannot be expressed in TypeScript (by interfaces)

Then, draft-06 support would boil down to:

• [ ] use @types/[email protected] -- extending where appropriate for backwards compatibility
• [ ] support new $id -- easy enough for names and resolving is off-loaded to some other library?
• [ ] handle booleans like {} and { not: {} } in more places (I don't know where)
• [ ] support const like a single enum
• [ ] update docs with new inexpressible keywords

For partial draft-07 support,

• [ ] readOnly support on interface properties (readonly modifier) and array (ReadonlyArray<T> modifier). I think this would solve #131?

[donabrams]

I started on this (and will be finishing it in the next few weeks once it gets reprioritized): https://github.com/donabrams/json-schema-to-typescript

I have some non-general requirements (like exposing a constant for each enumeration) that I'm not sure would be good to mainline, but I can try and keep those separate.

[victorandree]

I started a branch yesterday according to my own comment: https://github.com/victorandree/json-schema-to-typescript/tree/feat-draft-06

I think it covers the items I brought up, though I haven't tested every case (especially wrt booleans where schemas are expected).

@donabrams Curious what you mean by "like exposing a constant for each enumeration" -- I just treated them like a single-member enum. With just const, you get an inline constant. If you provide a name for the type, you get a constant type alias. With tsEnumNames (only an array), you get a single member enum.

[G-Rath]

Any update on this? It'd be nice to have support for even some of the easy basic things like const (which you could just map to enum internally)

[tomwidmer]

Note that Schema readOnly isn't really all that related to TypeScript's readonly - it isn't all that helpful to mark readOnly fields as readOnly. What the schema field usually means is that that field is ignored in request bodies (or alternatively, if present it's an error, or if present and modified from the current value it's an error - the exact meaning depends on the user, but to be on the safe side, clients shouldn't send read only fields in requests). I guess the simplest way to do that is to exclude the property from the interface, when generating the interface for a request context. But this means there would need to be a way of specifying what context you were generating for, and also a way to handle generating types for different contexts (perhaps adding a configurable suffix like 'Request' to type names). writeOnly also has an impact on generated types, and it means that the request type should include it, but the response type shouldn't.

This is important stuff for managing complex schema for CRUD operations (where you may have different fields relevant and/or required for GETs vs POSTs vs PUTs), but I'm not convinced it's better than just having multiple versions of your schema (probably generated from a shared source schema in some way).

See JSON Schema Spec

[petrosv91]

Any update on this?