Include certain node modules

[wmmihaa]

Is there a way to include some of the files in the node_modules folder? I'm using a .nycrc file as:

{
  "require": [],
  "include": [
    "**/*.js",
    "**/node_modules/microservicebus-core/lib/*.js"
  ],
  "exclude": [
    "**/*.test.js"
  ],
  "reporter": [
    "text",
    "lcov"
  ],
  "sourceMap": false,
  "instrument": false,
  "all": true
}

But files in the /node_modules/microservicebus-core/lib/ are not covered:

  3 passing (218ms)

-------------------|----------|----------|----------|----------|-------------------|
File               |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
-------------------|----------|----------|----------|----------|-------------------|
All files          |    31.95 |    18.89 |       10 |    31.95 |                   |
 SettingsHelper.js |    69.23 |    47.06 |       75 |    69.23 |... 96,101,104,113 |
 Utils.js          |    15.38 |     1.79 |        0 |    15.38 |... 32,233,234,235 |
-------------------|----------|----------|----------|----------|-------------------|

[pingynator]

It seems to be possible to include files from every folder expect node_modules.

Problem seems to be inside nyc: node_moduls/nyc/test-exclude/index.js line 126 and 133 in nyc version 11.8.0.
exportFunc.defaultExclude = [ '**/node_modules/**'

By default nyc excludes everything inside node_modules and files from node_modules can not be included. Sadly explicit includes do not overwrite implicit excludes.

BAD Workaround:
delete line 133 in node_moduls/nyc/node_modules/test-exclude/index.js
"/node_modules/"
(NYC Version 11.8.0)

Maybe a better workaround:
in .nycrc write an empty exclude:
exclude: []
and then use a test and require the node_module/... you want to be covered.
Working on some similar solution my self right now.

[antoniocascais]

Hi @pingynator !

Did you find a better solution for that work around?
Dealing with the same problem here :|

[pingynator]

Hey @antoniocascais :)

I tried some other workaround without using nyc. I am using a webpack-based solution. I have written my "own" webpack-plugin, which is pretty much the webpack-mocha-plugin.
So my solution isnt an (very) easy workaround and is suited for our use cases so that - at least for now - I won´t publish this solution. :/

It should be possible though to "rewrite" nyc and deploy your "own" nyc to your node_modules.
As far as I have seen it on the webpack-mocha-plugin side mocha is generating the coverage report data
(= json-object).
So you need to inject your node_module-files to the mocha-input. (Basically: Just look where mocha is getting called.)

Mocha is generating a json-object which you can manipulate. This object is the source for the report-files (f.e. html-report). So you can inject you own report data there, too. Although I would suggest not to do this.

[antoniocascais]

Hi @pingynator. Thanks for the response!

For now we also came up with a workaround (which was forking NYC and remove the logic to exclude the node_modules), but we don't want to have this as a final solution. We will keep digging and try to solve the problem in a proper way...

Thansk for the help! Your comment from 30th of May was really helpful in understanding why the coverage was not working properly 👍

[pingynator]

Hey @antoniocascais. I am glad you found a solution.

If you find a "proper way" to solve the problem I would be really happy to hear about it. :)

[antoniocascais]

Hi @pingynator !

We found a proper solution for our problem!

So, for a bit of context:

We had a NodeJs project with the following dir tree:

--node_modules (the one for 3rd party libs)
--src
---node_modules (for our own code)
----app
-----service
----lib
--package.json

We had our own code under our own node_modules because it was the easiest solution for navigating across the require files in our IDE.

When we found your post explaining why the files are not evaluated for the code coverage, we decided to rename our node_modules folder.
This lead to some problems: the requires stopped working. We needed to add the full path of the file and that's supper ugly.

After trying every solution that we found on google, the final one was having sub-modules.

We now have:
-- node_modules (the one for 3rd party libs)
-- src
--- main
---- app
---- service
----- package.json
---- package.json
---- lib
---- package.json
-- package.json

In the main package.json we declare the dependencies for the other package.jsons:

  "dependencies": {
    "app": "file:src/main/app",
     "lib": "file:src/main/lib",
  }

In app/package.json we declare the dependency for app/service:

  "dependencies": {
    "services": "file:services"
  }

And the services/package.json and the lib/package.json are just simple files without dependencies:

{
  "name": "services",
  "version": "0.0.1"
}

By doing npm i node will install all the sub-modules and will create symlinks in the node_modules folder to the directories where the code is. This way we can navigate across files in the IDE and we have all our code files being evaluated for code coverage!

This solution worked perfectly in our local machines, but then we had problems when deploying the code to CloudFoundry (which is the service that we use): for some reason that I still don't understand, the symlinks are ignored. So, the required files in the code were not found and the application wouldn't start.

We tried several approaches to solve this issue and we ended up writing a script that removes the folders with symlinks from node_modules and replaces them with a copy of the original folder.
It's not the prettiest solution ever, but it works.

So now we have a clean (in our opinion) solution for our local development and a not-so-clean solution for deploying the application.

Hope this helps and if you have any question please feel free to ask! 😄

[JaKXz]

We have had a lot of thrashing on this issue - #442 #352 #953 and many others... @wmmihaa do you have a link to a repo you could share?

[coreyfarrell]

[email protected] has been released to npm to allow easier testing. Please note that additional breaking changes will occur before 14.0.0 final is released. I'm closing this issue, you can monitor release progress at #1051.

This release contains a number of fixes which will make it easier to instrument some/all of node_modules - #912 and #977 in particular apply to this issue.