nyc.config.js in "type": "module" project

[robrich]

Current behavior

Goal: Cypress e2e coverage and Cypress component coverage don't overwrite each other.

or

Goal: Single coverage report covering both e2e & component tests.

Repro steps:

1. set package.json: "type": "module"
2. create dynamic config: nyc.config.js file with any options
3. run cypress tests: npx cypress run --browser chrome && npx cypress run --browser chrome --component

Expected behavior:

It loads the nyc.config settings then runs the test

Actual behavior:

ReferenceError: module is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and 'C:\path\to\my\package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at file:///C:/path/to/my/nyc.config.js:8:1
    at ModuleJob.run (node:internal/modules/esm/module_job:192:25)

or

Error: Failed to load nyc.config.js: require() of ES Module C:\path\to\my\nyc.config.js from C:\path\to\my\node_modules\@cypress\code-coverage\task-utils.js not supported.

Attempted work-arounds:

• Rename config to nyc.config.cjs: doesn't pick up config
• Rename config to nyc.config.ts: doesn't pick up config
• Change file content to ES6 module syntax: different error, but still errors

Desired behavior

No response

Test code to reproduce

see above

Cypress Version

12.11.0

Node version

20.1.0

Operating System

Windows 11

Debug Logs

No response

Other

No response

[mike-plummer]

@robrich Thanks for the report, and sorry you're having issues. There are so many landmines with these new module types.

This is really an issue with @cypress/code-coverage due to its unguarded use of require(..). I opened a new issue over there cypress-io/code-coverage#668 and will close this one in favor of that.

I'm assuming you tried to sort out a way to use the non-dynamic config via package.json or .nycrc, but I suppose it's tricky given the use case you're trying to fulfill. The only workaround that springs to mind is to do the instrumentation step manually and pass custom CLI params to nyc for each set of source files to use a different report-dir - it would work, but would be a bit of a pain