More Typescript migrations - switch to Typedoc

[joepio]

Related issue: #355

• Converted some of the most fundamental classes to typescript, including Node, Literal, BlankNode, NamedNode, Collection, Statement.
• Introduced a .types file for shared types.
• Included a temporary types-temp.ts file in project root as a reference file for documentation and keeping track of the ts migration process.
• The .isVar method is set to boolean values, instead of 0 or 1. This seemed reasonable, as it's only used for boolean type checks, and the existing types already define it as a boolean value.
• JSDoc is switched with Typedoc. Combined with typescript, it makes the documentation far more complete.
• Sometimes I had to make assumptions on date types, e.g. that a user will never create a Statement containing a Collection. These assumptions used to be implicit, but typescript forces us to make them explicit. This happens when you see type assertions (value as type).
• Literals can apparently be null or undefined, when nodes are created using the .fromValue method. This happens in the Statement constructor. See Node.fromValue() type assumptions - null / undefined #362.

[Vinnl]

Overall looks good. Unfortunately, Git wasn't able to recognise all renames of .ts files to .js ones, so I hope I only ignored what should be ignored :)

I'm not familiar enough with rdflib to be able to give a valid opinion on the isVar conversion to a boolean.

Looking forward to getting this merged!

[joepio]

Thanks for all the feedback @Vinnl, I've made the changes you requested (except for the type guard in literal.ts, that changes the behavior and was a little tricky).

[Vinnl]

Thanks Joep, looks good as far as I can see - though I'd like @timbl's opinion on the isVar changes, as I have no idea on the implications. I'll assign this to him, but if you'd like to get this merged faster, you could also split it up into a separate PR. I'm fine with either.

One question though: how would the type guard change the behaviour? For example, if we changed

if (Object.prototype.hasOwnProperty.call(value, 'termType')) { /* ... */ }

to

if (isNode(value)) { /* ... */ }

function isNode<T>(value: T | Node): value is Node {
    return Object.prototype.hasOwnProperty.call(value, 'termType')
}

wouldn't that result in exactly the same behaviour?

[joepio]

@Vinnl I've added these type guards in a new branch. Shall I update this PR to include the changes from that branch, or shall I submit it as a separate one? The changes from this one are quite big.

[Vinnl]

@joepio Generally, separate PRs for separate functionality is easier to review for me, so I'd prefer a new one, marked as dependent on this one. I see more changes than just type guards though :)

[joepio]

@joepio I see more changes than just type guards though :)

Very true - the biggest one is RDFJS Taskforce compatibility.

[joepio]

Yesterday discussed to first merge #358. I'll rebase my typescript fork (which includes the changes from this PR + a lot more) on master after that, and then will issue a new PR.

[Vinnl]

@joepio #358 has now been merged, so feel free to rebase.

[joepio]

Replaced by #373