fix: Remove esModuleInterop from ts-node

[sainthkh]

User facing changelog

This option prevents users from not using it.

Additional details

Why was this change necessary?

This option is too opinionated.

What is affected by this change?

A project will break if it meets these 3 conditions:

1. no tsconfig.json file
2. plugin/support files in typescript
3. use import Foo from 'foo' style

Any implementation details to explain?

N/A

How has the user experience changed?

N/A

PR Tasks

• Have tests been added/updated?
• Has the original issue been tagged with a release in ZenHub?
• Has a PR for user-facing changes been opened in cypress-documentation?
• [N/A] Have API changes been updated in the type definitions?
• [N/A] Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[bahmutov]

We need a test for this, using a TS project fixture in packages/server and e2e test probably is enough for this

[brian-mann]

The e2e project here is confusing... it appears we are attempting to test the failure case of an import with esModuleInterop: false right?

It's weird that there are spec files (but don't ever even get run) because the failure happens in the pluginsFile.

I would prefer we actually use a real test failure in a spec file (for instance, asserting that the exported module does or not does have the add function).

It would actually be better to assert in the affirmative and receive a passing test that would otherwise fail with esModuleInterop: true by default.

The test name itself (and comments) could explain why, and reference the original issue. As it stands its very confusing because there's no context as to why the snapshot value of the e2e test is correct or not.

[sainthkh]

It seems that there is no alternative.

1. About using spec files.

As we know, spec files and plugin/support files use different TypeScript transpiler settings. As for spec files, using opinionated typescript setting is necessary because tsify doesn't have transpileOnly option and that's the only way not to lose the traspile speed.

Because of that, using spec files cannot test if esModuleInterop can be overridden for support/plugin files in Cypress.

I explained this in the plugin file and removed unnecessary tests in spec files.

2. Creating affirmative test.

I found out that it's impossible to create an affirmative test with math.add. Because:

import	esModuleInterop	Result
import * as math from './math'	false	pass
import * as math from './math'	true	pass
import math from './math'	false	fail
import math from './math'	true	pass

I changed it to simply export add function.

[robcresswell]

Hello! Is this likely to land in 5.0? See to have stalled for a few weeks. Is there anything I can do to help?

[jennifer-shehane]

@robcresswell We're still reviewing the final 5.0 features. Hopefully this gets in. #7753

[robcresswell]

Ah sorry, thats poor research on my part. Thanks for the link @jennifer-shehane!

[jennifer-shehane]

@sainthkh Will this require any notes on our Migration Guide? Any updates people will need to be aware of for changes they need to make? I just noticed this is the only 5.0 PR that doesn't have specific docs updates.

[sainthkh]

When a user doesn't have a tsconfig.json file or define esModuleInterop: true, Cypress didn't fail in 4.x, but it might fail after 5.0. Because Cypress now uses the default esModuleInterop setting of TypeScript.

I used 'might', because it wouldn't fail when a user didn't use import syntax.

[chrisbreiding]

Merging this into #8143 and continuing any work there.