Implement $id and $ref properly

[schani]

The current situation is a mess, and probably quite buggy. We have two separate schema crawlers - one in the canonizer, the other one in the type-building parser. We mix canonical refs and virtual refs too much.

Here's what I think a proper implementation should do:

• Have one type for traversing schema objects. It has to combine the schema object with its location, which can be any number of refs, I think. See the relevant section in the JSON Schema spec. The only way to traverse a schema is to use that type.

• Whenever a new schema file is loaded every single one of its refs is registered by the canonizer, so that no traversing is necessary to look up a $ref.

• When a $ref is resolved, the canonizer's map is consulted first. If the ref isn't registered, candidates for its address have to be attempted to fetch. There might be more than one, since a ref to foo.schema could mean foo.schema in the current directory, or relative to the where the referencing schema is. Alternative opinion: it can't mean the current directory, because then it would be dependent on where quicktype is called from. So either we've registered foo.schema before, via some $id, or we interpret it relative to the referencing schema.

The whole point of this is to decouple everything that's going on, and to have only one, clear place where policy is decided.

[Frobitz66]

Any nibbles on this task from TS proficient folks ?

[Hulkmaster]

wow, seen quicktype referenced as modern json schema to typescript parser, but found out it cannot parse $refs

used https://www.npmjs.com/package/json-schema-to-typescript in the end