Type Guards for union type nodes report false negatives

[alex-ketch]

Currently the isA and isType type guards only compare the passed type value, and don't take into account broadening of types, and will return false negatives.

isA('CreativeWork', {type: 'Article', ...}) // false
isA('MediaObject', {type: 'ImageObject', ...}) // false

isType('CreativeWork')({type: 'Article', ...}) // false
isType('MediaObject')({type: 'ImageObject', ...}) // false

These become an issue when used as filters in Encoda, mistakenly discarding nodes as being invalid.

Possible solutions:

1. Create a mapping between types that are supersets of others, and use it to find the necessary typeMap and use it to test the node in question. Concern here being that I'm not 100% how to provide an exhaustive type signature just for these nodes, so it will have to be maintained manually.
2. Create more typeMap filter variants, and deprecate the usage of isA and isType functions. Drawback being more changes to Encoda, and clunkier ergonomics for defining ad-hoc type .guards

[nokome]

Yes, I agree this is an issue. I suggest that we go down the route of (1). We already have the "mapping" in the form of each type's type e.g.

export interface MediaObject extends CreativeWork {
    type: 'MediaObject' | 'AudioObject' | 'ImageObject' | 'VideoObject';

but unfortunately those are not available at runtime. But, if we generated enums instead we would get the lookup table at runtime to be able to be used in type guards:

enum MediaObjectTypes {
   MediaObject = 'MediaObject',
   AudioObject = 'AudioObject',
   ImageObject = 'ImageObject',
   VideoObject = 'VideoObject'
}
export interface MediaObject extends CreativeWork {
    type: MediaObjectTypes

[nokome]

Having though about this some more, I think we should address this at the JSON Schema level, with derived typings in each language. In the schema, we also need to be able to say things like "a CreativeWork, or anything that extends it". For, that we created CreativeWorkTypes.schema.yaml which is a manually authored (and thus potentially wrong) list of all types derived from CreativeWork.

Instead of manually authoring files such as CreativeWorkTypes.schema.yaml and manually writing files such as ts/util/type-maps.ts, I suggest that:

• In ts/schema.ts we generate CreativeWorkTypes.schema.json, MediaObjectTypes.schema.json etc based on the descendants property.
• In ts/bindings/typescript.ts we generate type-maps.ts from those *.schema.json files
• In guards.ts we add a isDerivedFrom or isInstance or doesExtend that checks against those type maps (that would keep isA, for cases where you want to check that the node was of a particular type).

[stencila-ci]

🎉 This issue has been resolved in version 0.33.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v0.33.0

Your semantic-release bot 📦🚀