Javier Pedemonte

Seeing this as well. It is impacting the use of `@cypress/code-coverage`, since it tries to read the `nyc` config from `package.json`, but is now [looking for that within the Cypress...

I ran with `DEBUG=cypress:*` and here's what I see: - Initially, I see it passing the correct `cwd`: > cypress:cli spawn args [ '--no-sandbox', '--', '--run-project', '/Users/pedemonte/projects/myproject/client', '--config-file', 'cypress/config/ci.config.ts', '--testing-type',...

It appears that this is an intentional (but undocumented?) change in 10.0 (see [app-lifecycle.md](https://github.com/cypress-io/cypress/blob/4626f7481c9904fec484aa167a02e0197a3095c4/guides/app-lifecycle.md)), wherein the config file is now run in a separate process, with `cwd` changed to the...

FYI, my current workaround (until this is fixed either here or by plugins) is the following: ```js function requirePluginWithProjectRoot(pluginPath, on, config) { if (config.projectRoot) { const cwd = process.cwd(); process.chdir(config.projectRoot);...

Note there is another vulnerability (I can open another issue if necessary): [CVE-2021-3749](https://cve.circl.lu/cve/CVE-2021-3749), which is only fixed in `axios` 0.21.2+ (there were some follow on fixes, so 0.21.4 seems to...

Update: `axios` was actually incorrect in versions 0.21.1 and lower -- `null` is a valid value to stringify. So `apisauce` is incorrect in defaulting to `data = null`, since this...

Opened https://github.com/infinitered/apisauce/issues/276

Looks like plugin could be updated to use `config.projectRoot` instead of `process.cwd()`.

Agreed, need someone from Cypress to chime in. In the meantime, I have a different workaround I'm currently using, which mimics the previous (9.x) behavior: https://github.com/cypress-io/cypress/issues/22689#issuecomment-1210805276

Removing `"all": true` from the config makes this work better. Here are the same tests from the screenshot in description:  But now...