Home > Net >  npm run coverage fails with "require(...).internalModuleStat is not a function"
npm run coverage fails with "require(...).internalModuleStat is not a function"

Time:02-15

When we run our tests with npm run test, they pass. When we run with npm run coverage, though, some fail with this error:

'internal/modules/cjs/loader.js:58\n'  
    "const internalModuleStat = function (f) { return require('fs').internalModuleStat(f); };\n"  
    '                                                               ^\n'  
    '\n'  
    'TypeError: require(...).internalModuleStat is not a function\n'  
    '    at internalModuleStat (internal/modules/cjs/loader.js:58:64)\n'  
    '    at stat (internal/modules/cjs/loader.js:137:18)\n'  
    '    at Function.Module._findPath (internal/modules/cjs/loader.js:667:16)\n'  
    '    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:967:27)\n'  
    '    at Function.Module._load (internal/modules/cjs/loader.js:862:27)\n'  
    '    at Module.require (internal/modules/cjs/loader.js:1042:19)\n'  
    '    at Module._preloadModules (internal/modules/cjs/loader.js:1296:12)\n'  
    '    at loadPreloadModules (internal/bootstrap/pre_execution.js:449:5)\n'  
    '    at prepareMainThreadExecution (internal/bootstrap/pre_execution.js:73:3)\n'  
    '    at internal/bootstrap/pkg.js:7:1\n'

What can be going on here?

CodePudding user response:

This error message can happen in many setups; it can be hard to discover what is going on in your case. Here we share a solution for our own context, with some explanation about why it worked for us and might work for you.

There is a common (although not unique) root cause to similar problems:

Something may be messing up with the values of the NODE_OPTIONS variable.

To understand what it means, see what happened to us.

A case study

nyc (the test coverage tool we use) sets an environment variable called NODE_OPTIONS. However, pkg, which we also use, depends on this variable, too. So when we run coverage, the variable is changed by nyc, and pkg gets somehow lost.

Our solution was to reset the variable before running the tests. In our case, we use Mocha, so we had a line like this in our package.json:

"scripts": {
  "coverage": "nyc --reporter=lcov --include='src/**/*.js' npm test",
  "test": "./node_modules/.bin/mocha --require @babel/register --recursive --exit",
}

We just added NODE_OPTIONS='' before calling mocha:

"scripts": {
  "coverage": "nyc --reporter=lcov --include='src/**/*.js' npm test",
  "test": "NODE_OPTIONS='' ./node_modules/.bin/mocha --require @babel/register --recursive --exit",
}

Now, npm run coverage runs nyc, which sets the variable as needed. nyc then calls npm run test, whose script cleans up the variable.

Your mileage may vary—but may be close

It is unlikely you had the very same problem we had. Yet, you may have changed NODE_OPTIONS in some other way. The problem can be something else, but I would indeed check NODE_OPTIONS as a possible culprit.

  • Related