Cypress: Opinionated TS transpilation without overrides is problematic

[robcresswell]

Current behavior:

Cypress recently added better native support for TypeScript, a great step forward, thanks!

However, part of this process added the following defaults for ts-node:

https://github.com/cypress-io/cypress/blob/bdcfe42f790a6f0e73e8f4ae2133c62df2de349d/packages/server/lib/util/ts-node-options.js#L13

Specifically, esModuleInterop is problematic. This is an opinionated transpilation, and cannot be overridden. Typically when working working with a JS / TS mix, you can either use imports such as

import * as Foo from 'foo';

or you can enable esModuleInterop and do

import Foo from 'foo';

In my case, I chose the former, to reduce the "magic" that is done by the TypeScript compiler; however, because Cypress enforces the latter, I get lots of errors along the lines of

TypeError: Foo is not a function

Desired behavior:

A test frameworks authors should not enforce an opinion about how I build my application; this esModuleInterop value should be possible to override. I tried manually changing it by editing the downloaded Cypress JS code in ~/.cache, and the tests ran as expected.

Test code to reproduce

Working on a minimal reproduction, please give me a bit of time :smile:

Versions

Cypress: 4.7.0

┆Issue is synchronized with this Jira Features by Unito

[jennifer-shehane]

This change was made in 4.6.0 as part of https://github.com/cypress-io/cypress/pull/7197 so perhaps @bahmutov can speak to why this decision was made.

[bahmutov]

I did move it, but this option was already there https://github.com/cypress-io/cypress/pull/7197/files#diff-0f01b0186fbd767d98bd689a60ddd05aL193

I do wonder if we really need it or not, and if we should overwrite it from the user's TS config

[robcresswell]

I feel quite strongly that enforcing this is a mistake on Cypress' part, though I can see why it was done. Haven't quite had time yet to put up a minimal repro, though it seems that my intent is at least understandable without it, for now.

Is this something I should put up a PR for? I don't know how accessible this is a Cypress newcomer, though I can see you've got a lot going on :sweat_smile: and I'm happy to give it a go.

[bahmutov]

@sainthkh do you remember why you have set esModuleInterop: true? Was there a specific reason to override user's setting?

[sainthkh]

It was mainly because I misunderstood the default behavior of tsnode. I thought it would load tsconfig.json from Cypress internal ones. But I was wrong.

Maybe I was more familiar with import Foo from 'foo' and felt it was a bit weird that we cannot use it without tsconfig.json. It seems that I did too much.

But removing it would break some test setups with no tsconfig.json + ts plugin/support files + import Foo from 'foo'-style import. It's a bug, not a breaking change. Right?

[robcresswell]

@bahmutov @sainthkh Any thoughts on fixing this?

[sainthkh]

The only block for me is to decide if it's a breaking change or a bug. If it's a bug, it can be fixed immediately. If it's a breaking change, we need to wait for 5.0.

[chrisbreiding]

@robcresswell Can you provided a reproducible example of this? We're looking into changing this default for 5.0, but I can't create a case where import * as Foo from 'foo' fails.

[robcresswell]

@chrisbreiding I've pushed an example to https://github.com/robcresswell/cypress-example

Let me know if you have any difficulties; there's an explanation in the README.

[cypress-bot[bot]]

The code for this is done in cypress-io/cypress#8143, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[cypress-bot[bot]]

Released in 5.0.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v5.0.0, please open a new issue.