Allow --nycrc-path to be absolute

[ehmicky]

At the moment --nycrc-path value must be relative. It would be great if this could be absolute as well.

My use case: I have a module with shared development tasks that I use in many libraries. One of those tasks is running tests with nyc. The nyc configuration is always the same, i.e. I want to specify it inside that shared module instead of inside each library.

I cannot use --cwd as it would impact test coverage (not just configuration loading). I.e. I need to use __dirname with an absolute path.

My current workaround is to use CLI flags instead of a configuration file, but a configuration file would be better.

[coreyfarrell]

I'm looking into creating a proper fix for this. That said I would recommend instead using nyc.extends in your package.json instead of using any CLI flags. So in your package.json:

{
  "nyc": {
    "extends": "@my-org/nyc-config"
  }
}

You would also run npm i -D @my-org/nyc-config, obviously replace that module name with whatever name publish your shared config under.

[ehmicky]

Thanks that would work. However I am trying to abstract any development tool in that shared module. I.e. when development tooling changes, my libraries don't need to be updated.

I.e. I am avoiding adding any configuration property or file related to development/build tasks in my libraries, and instead only point to that shared module.

[coreyfarrell]

Not following the last statement, you need to add --nycrc-path somewhere, wouldn't that be in your npm test script? It might help me understand if you pointed to an example repo.

[ehmicky]

Each of my libraries install a module gulp-shared-tasks as a devDependency. They also have a gulpfile.js that just require that module.

gulp-shared-tasks exports several Gulp tasks, including gulp unit, which basically runs nyc ava test/.

Links to: gulp-shared-tasks, a library that uses it and the line of code that actually calls nyc.

The reason of the setup is I am trying to reduce repeated code between libraries to the minimum. This includes not only code, but also configuration properties/files. I even try to remove configuration files that merely forward to another module.

[coreyfarrell]

@ehmicky this will be supported by the next release of find-up, once that is released and we upgrade this issue will be fixed. The next version of find-up will require node.js 8 so the plan is that this will be fixed in nyc@15. I can't promise 15.0.0, it depends on when the next find-up release occurs.

[ehmicky]

@coreyfarrell thanks for the update and the work downstream with that PR on find-up!

[coreyfarrell]

The new release of find-up has been made and will fix this issue once we're able to release nyc@15. I'm going to close this issue as no further action will happen here, bumping find-up will happen as part of a mass dependency update. Please follow #1104 for progress updates about the next release of nyc.

[ehmicky]

Thanks, that's great!