Use type variables in TypeScript typings instead of never

[tetsuo]

F.of(x => y => [x, y])
  .ap(future1)
  .ap(future2)

TSC throws a compilation error in here, since of always assumes that it doesn't throw a rejection.

Adding a new type variable instead using never should fix the issue, but it might break other things where the error type is not specified explicitly.

@Avaq I added it to of and after. Anything else that needs to be fixed?

[codecov-io]

Codecov Report

Merging #230 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #230   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          48     48           
  Lines        1187   1187           
=====================================
  Hits         1187   1187

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c419778...613291d. Read the comment docs.

[Avaq]

I believe this approach is the better one in all instances where never us used.

[Avaq]

Would you like to make the proposed adjustment to all the other never using functions (except value), @tetsuo? Or shall I make these changes and append them to your PR?

[tetsuo]

The final build requires @types/node typings for some reason, which is installed for Node.js v10 by default. This was causing builds to fail during declaration file testing. It looks like the default node typings require Map, Set and so on. I included ES6 typings too. We can also try installing one of the earlier versions of @types/node. Also updated TypeScript to 2.8.x just for kicks.

Should we consider adding a package-lock.json file by the way?

[Avaq]

This looks great! Thank you.

I remain of the opinion that package locks are only relevant in "root" level packages, eg applications. It's a feature to accommodate safer deployments. When installing a package as a dependency, I believe its package lock is ignored. Instead, I use greenkeeper to react to broken dependencies.