Split config extends functionality to separate module?

[coreyfarrell]

Ref istanbuljs/load-nyc-config#2

The module in question is to be used by both nyc and babel-plugin-istanbul. The babel plugin does not use yargs (no CLI processing), but we want it to load the same configuration as nyc. Currently extends is not processed. I could probably use const applyExtends = require('yargs/lib/apply-extends') but this is not documented as a public API and the babel plugin has no reason to install yargs as a whole. It would be nice if lib/apply-extends.js were it's own stand-alone module so the babel plugin could get identical config loading functionality as nyc without pulling in all of yargs.

[bcoe]

well we're at it we should address this bug: #1372 😝

I'm a little torn, because I've tried to be pretty conservative about splitting yargs into packages:

• yargs has more dependencies than many of the other popular CLI frameworks floating around (and has been criticized for this).
• it adds extra maintenance burden to manage additional modules.

If we think that extends' logic is valuable enough to extract, perhaps we can just continue vendoring it inside yargs, but extract it into its own module; then just add a note in the file that it shouldn't be edited in place.

[coreyfarrell]

I was thinking to avoid pulling all of yargs into babel-plugin-istanbul but realistically any user of this babel plugin likely uses nyc as well or some other development module that uses yargs. As I mentioned I can get the function I need by using require('yargs/lib/apply-extends'). Normally breaking changes to an internal API would not spawn a semver-major release. If we can treat this as a public API entry-point (breaking change to it is semver-major), then I will be happy enough. Even if it's not a publicly documented API, just a comment in lib/apply-extends.js saying that the function is a public API.

[bcoe]

@coreyfarrell what I don't love about this is, you do end up pulling in the 224kb yargs package, which folks are bound to call attention to 😛

Let's split it into a module? and I'll just vendor it.

[coreyfarrell]

Actually I'm planning to vendor it into @istanbuljs/load-nyc-config, this way I can do things more specific to nyc - for example support "extends": "./something.yml".

See istanbuljs/load-nyc-config#4

Leaving this ticket open for now so we can decide if some of the enhancements I made should be contributed back to yargs.