feat: Support `nycRC()` in configuration object

I’m toying with programmatically created configurations at @cfware/nyc. This module exports a class with methods implemented as both static factory functions and chainable non-static manipulation functions. The idea is that you could create an nyc.config.js as follows:

'use strict';

module.exports = require('@cfware/nyc')
  .fullCoverage()
  .include('lib/**')
  .exclude('lib/do-not-cover.js')
  .settings;

This example has two main benefits over normal declarative config:

• .fullCoverage() sets multiple properties (similar to tap --100)
• .exclude() does not clear defaults so lib/do-not-cover.js is in addition to testExclude.defaultExcludes.

I’d love to avoid having to explicitly use .settings in my nyc.config.js files. This could be supported if the nyc lib/config-util.js did something like:

if (Symbol.for('nycrc') in config) {
  config = config[Symbol.for('nycrc')]
}

In all supported versions of node Symbol.for('nycrc') === Symbol.for('nycrc') so this would allow nyc to pull it’s configuration from config generator objects such as mine. I’ve already verified that adding this code does not break any existing tests.

@bcoe @JaKXz @isaacs any thoughts / objections?

[bcoe]

@coreyfarrell seems reasonable to me 👍; I think what I’ve seen other libraries do is just have the default export be an object with the config (which I think is what we support today if you have an nycrc.js) – what advantages are there to having a toNYCRC() method?

[coreyfarrell]

Adding support for nyc.config.mjs in nyc 15 has incidentally made this possible. Since we have to await the result of the config load it is now possible for configuration generators to be PromiseLike objects, so:

class ConfigGenerator {
  // Add methods / properties for constructing `this[settings]`

  async then(fn) {
    return fn(await this[settings]);
  }
}