chore(ts): tsify satellite modules

[mleguen]

Part of the 2nd step of #1586: this PR tsifies all "satellite" modules of yargs, leaving all "core" modules still in js (yet).

Although it touches 21 files:

• its review should be pretty straightforward as the satellite modules are small, and not much changes in most files
• modules are handled one by one, in different commits (with a 1st commit for renaming, and a 2nd one for tsifying)

Points of attention, however:

• I had to switch from standard to standardx for linting, as there are some known false positives with standard and typescript (see https://standardjs.com/#typescript)
• 1st benefits of switching to typescript: it detected a not-handled null in apply-extends. I added an explicit exception to cover this case (though it was already implicitely handled, as it made fs throw a few lines below)

[bcoe]

again, once we're a ways along with the conversion, I would be excited to see us drop eslint for gts, but this is looking awesome (and I appreciate the incremental approach).

Even though none of these changes are breaking, I would like to make TypeScript part of the next major of yargs (this will be a big announcement).

[mleguen]

I would be excited to see us drop eslint for gts

Do we really have to wait for yargs not to support node 8 anymore for this?

Linting tools are only dev dependencies, so couldn't we just remove linting checks from node 8 tests? And move to gts 2.x for other node versions?

[bcoe]

@mleguen I would like to wait because many (probably thousands) of people using yargs are relying on @types/yargs, once we start moving towards publishing our own types, I believe it's an improvement, but it will be a breaking API change for all of our TypeScript users (I'm of the opinion that we should treat breaking TypeScript changes as breaking changes, it's miserable when upstream TypeScript dependencies break their interface).

[mleguen]

@bcoe I agree with you on the fact that publishing our own types should be considered as a breaking change (this would impact me as a yargs user), but as long as we do not tsify index.js or yargs.js at the project root yet, there should be no impact on ts users.

So IMHO, this current PR should not be considered as a breaking change, nor switching to gts 2.x and disabling linting in node 8 test (which was what I was suggesting in my previous message).

Would this be OK for you?

[bcoe]

@mleguen this makes sense to me, as long as we keep the Node 8 tests for the time being for the suite, and make it a breaking change once yargs and index are exported.