[CT] Fix Vite 5 CJS Deprecation Warning and Prepare for Vite 6

[haoqunjiang]

Current behavior

When using Cypress Component Testing with Vite 5, if vite.config.ts is used, a CJS Node API deprecation warning will always appear, despite "module": "NodeNext" or "module": "ESNext" being specified in the root tsconfig.json and "type": "module" being present in package.json.

Desired behavior

Should not show the CJS warning because vite.config.ts should be treated as an ES module when type: "module" presents.

Test code to reproduce

git clone https://github.com/sodatea/vite-5-cypress-reproduction
cd vite-5-cypress-reproduction
pnpm i
pnpm test:unit

The following warning will be printed:

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

and

We detected that you have versions of dependencies that are not officially supported:

 - `vite`. Expected ^2.0.0 || ^3.0.0 || ^4.0.0, found 5.0.0.

If you're experiencing problems, downgrade dependencies and restart Cypress.

The latter issue has already been tracked at #28347

Cypress Version

13.5.1

Node version

v18.18.2

Operating System

macOS 14.1

Debug Logs

No response

Other

I guess this is because of the limitation of ts-node that Cypress uses underlyingly to load the configuration files:
TypeStrong/ts-node#1791 (comment)

Considering Vite 6 will drop CJS Node API, I think Cypress needs to either work around this limitation or move away from ts-node as early as possible.

[haoqunjiang]

IMO, getting rid of ts-node may be a better option here. Because there are other well-known issues of this tool.
For example, it doesn't support solution-style tsconfigs, forcing us to specify a compilerOptions.module option in the root tsconfig.json, even though that field doesn't mean anything for any other tool. This is not a good DX.

[MikeMcC399]

The warning

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

links also to

• Moving Vite's Node API as ESM only vitejs/vite#13928

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[MikeMcC399]

• Related to issue Vite v5 gives CJS deprecation warning with Component testing #29557

[gweesin]

currently caused by require.resolve.

// "vite-dev-server" is bundled in the binary, so we need to require.resolve "vite"
// from root of the active project since we don't bundle vite internally but rather
// use the version the user has installed
export function getVite (config: ViteDevServerConfig): Vite {
  try {
    const viteImportPath = require.resolve('vite', { paths: [config.cypressConfig.projectRoot] })

    debug('resolved viteImportPath as %s', viteImportPath)

    return require(viteImportPath)
  } catch (err) {
    throw new Error(`Could not find "vite" in your project's dependencies. Please install "vite" to fix this error.\n\n${err}`)
  }
}

[joshbuker]

Any way to resolve this?

[AtofStryker]

It looks like vite 6 has not yet removed the vite cjs API yet, so this does not block vite 6 support.

For Cypress to get rid of using the cjs API requires some involved steps

• Changing the require.resolve and require in getVite to use dynamic import syntax.
• Changing the way @cypress/vite-dev-server is bundled, changing the target in the tsconfig

from

"module": "commonjs",
"moduleResolution": "node",

to

"module": "ESNext",
"moduleResolution": "node",

This will make the package compile down to ESM.

• We pull in the dev server via running the plugins scripts, which are all CJS. We would need to update run_require_async_child and require_async_child, which
  is used when we scaffold the end users project config in the data-context package (also has references in the migration manger)

We would also need to make sure moving the plugin manager over to ESM could still work with end user cjs plugins.

Either way, the work here is fairly involved.