integrate TS definitions

[KiaraGrouwstra]

No description provided.

[KiaraGrouwstra]

This PR would integrate TypeScript definitions based on my fork of @donnut's typescript-ramda, based on discussion here.
Points of note:

• I'm not proficient at legal stuff, I hope merging the license to add Erwin's name checks out for both sides.
• Currently using a TS nightly to get access to some of the newer features (e.g. keyof).
• For a few of the "walls of typings" I added generator scripts (these use Ramda) to facilitate future systematic edits.
• I tried adding its tests in the npm pretest script. Note that I'm having it use the local TypeScript so as to control its version. For me on a Windows environment, this local path ./node_modules/typescript/bin/tsc doesn't work however -- to run the test this way I had to use Linux subsystem for W10. I'm open to suggestions there to make it run tests in Windows without workarounds again.

[CrossEye]

I have no competence in this area. Is there someone who feels up to a review? @donnut? @arcseldon? Someone else?

[KiaraGrouwstra]

Extra considerations:

• I wonder if we may want to handle TS tests separately somehow. In this pretest script now, they would become a blocker (exit with error) if a TS test would fail. This is unfortunate if used as-is in Travis, since it would place this burden on Ramda contributors who might not be familiar with TypeScript. If we were to use a separate test script though, this might clash with Travis's reported results being fairly... boolean, not seemingly meant for such distinctions (afaik).
• A merge would mean branches between Ramda and Typescript-Ramda can no longer be orthogonal. This may not be a big deal -- so far over there I've only just suggested a first alternate branch. I do not currently foresee many more cases like this.
• NPM versioning would by necessity become tied. Note it seems so far the typings had already used a versioning similar to Ramda, but I could foresee it being potentially nice for the typings to be able to publish updates with a potentially higher frequency than might be necessary for Ramda. This might be a reason against a merge.
• The obvious bright side, TS users of Ramda being able to get typings without additional effort / consideration of versioning.

[KiaraGrouwstra]

Having talked to @donnut a bit further, the versioning point is one we both consider a concern.
For the typings it may well be desirable to be able to publish updates on a more frequent basis: as bugs get fixed, we gain new realizations / abstractions, or TypeScript releases new features. For TS typings, such a casual release schedule might make sense, as it would largely consist of safe fixes, rather than involving breaking changes.

I imagine in a merged context, this might make for undue pressure toward Ramda, where releases are a bit more formal, involving full copies of the documentation for users of previous versions. With that in mind, perhaps the most elegant path would be for us not to merge in, but to continue supporting users of Ramda + TypeScript without otherwise getting in your way.

Might this line of thinking align with your views @CrossEye?

[CrossEye]

@tycho01:

That might make the most sense. It's probably the easiest way to start out. If we want to alter this later, we could always consider adding point-releases if it needed to change between Ramda versions. My larger versioning concern is actually in the other direction. I just started pulling together a new version for Ramda itself. They don't happen (at least yet) on any regular cadence. But I would not enjoy having to chase down maintainers of such things as this in order to have a complete release ready. Maybe that's the price of maturing, but it's not one I feel really ready to pay.

[KiaraGrouwstra]

Yeah, I feel you there, thanks for being straight-forward.
In that case, let's close this, perhaps until the time such considerations were to change.