Support TypeScript 4

[nweber-gh]

What is your Test Scenario?

We are using TypeScript version 4, which is not compatible with TestCafe's semver of ^3.3, so code that compiles fine in our repository may not compile when running in TestCafe (die to differences between versions 4 and 3). TestCafe should be able to work with the version of TypeScript in my repository.

What is the Current behavior?

Compilation issues within TestCafe for code that compiles in my repository.

What is the Expected behavior?

Code compiles in TestCafe.

What is your web application and your TestCafe test code?

Normal TestCafe code written in TypeScript, using features supported in TS 4 but not TS 3.

Steps to Reproduce:

1. Author a TestCafe test in TS using TS 4 compatible features that aren't support in TS 3.
2. Compile files in repository specifying TS 4 dependency - observe no errors.
3. Run TestCafe with file - observe compilation errors.

[AndreyBelym]

Thank you for your report. TypeScript 4 is not supported at the moment. We need to test it for breaking changes and publish a minor or a major release. Please stay tuned for updates in this thread.

[nweber-gh]

The issue is more that it's a painful experience to force a project's TypeScript version to be in lockstep with TestCafe's version. In our example, all of the code in our large monorepo is happily using TS 4, with the exception of our e2e tests. We either need to:

1. Not upgrade TS to a version incompatible with TestCafe
2. Author e2es differently from the rest of our codebase

Both of these are pretty much non-starters. The former is prohibitively restrictive. The latter is not well supported in IDEs (i.e., VSCode uses "a TS version" for the entire IDE and it doesn't switch contextually based on active file directory).

[bdwain]

ideally testcafe would use my project's version of typescript rather than its own. and it could just specify a range of supported versions with a peer dependency

[AndreyBelym]

I understand that it is a serious issue for you and all other TypeScript users. @bdwain, I think peer dependencies won't play well here, since we try to provide out-of-the boxTypeScript support.

Could you please try to install the test build attached to this post? It allows using a different TypeScript version instead of the one that comes with TestCafe. With this experimental version, you can set the TESTCAFE_TYPESCRIPT_PACKAGE_PATH environment variable to the path to a custom TypeScript package, and TestCafe will use it instead of the preinstalled dependency.

You can install the test build with the following command:
npm i https://github.com/DevExpress/testcafe/files/5208261/testcafe-1.9.2.tar.gz

testcafe-1.9.2.tar.gz

[bdwain]

thanks @AndreyBelym , but this sounds like it won't use our tsconfig.json file? We want it to use that too.

Can testcafe default to using the preinstalled version of testcafe if it detects one, and if not, use its bundled version? And either way, use a local tsconfig if it detects one?

[AndreyBelym]

Changing the TypeScript version does not relate to tsconfig.json in any way. We wanted to load tsconfig.json automatically from the current working directory, but it was considered a breaking change. So, it's very unlikely that we can implement this until [email protected].

You can use the --ts-conifg-path option to supply your TypeScript configuration in the same way in both the modified and current versions.

I think we can detect a different TypeScript version if we start searching for a package from the current working directory. However, we should first check that everything works fine when an external package is specified manually.

[bdwain]

oh cool i didn't know that option existed. I will test this change.

[bdwain]

This seems to work pretty well! But there are 2 minor issues that I think should not be too bad to fix.

The first issue is that noImplicitAny is explicitly set to false (even though false is the default setting). While this is fine if I set noImplicitAny in my config to true (my true value will override the false default), it causes an issue if I used the strict option in my tsconfig, which is a shortcut for a bunch of strict settings, including noImplicitAny (Enable all strict type checking options.
Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictBindCallApply, --strictNullChecks, --strictFunctionTypes and --strictPropertyInitialization). This ends up causing a problem because the merged config file ends up having both strict: true and noImplicitAny: false, which typescript interprets as applying all of the strict settings except noImplicitAny, even though I as the end user only set strict to true and am expecting it to apply all of its settings.

I think the simplest thing would be for the built in config to just not set noImplicitAny at all and rely on the default of false. That should work the same in all cases right now except the case I ran into, which arguably is behaving incorrectly anyway. Alternatively, you could detect if the provided config sets strict, and if so, do not set noImplicitAny, but otherwise do set it to false.

The other issue I ran into is more cosmetic. The warnings that get output

You cannot override the "target" compiler option in the TypeScript configuration file.
You cannot override the "module" compiler option in the TypeScript configuration file.

are kind of odd because almost everyone who has their own tsconfig will set target and module in it, and i think it's just kind of understood that if you reuse it for testcafe, your target and module won't matter when running it and may get overwritten. Since the error isn't really actionable, it would be nice if we could disable it somehow (or if it just didn't exist).

Other than those 2 small things, I think everything looks to be pretty good.

[AndreyBelym]

Thank you for your feedback. noImplicitAny: false was introduced as a default setting in earlier TestCafe versions, so we cannot remove it without the risk of breaking user tests. I created an issue for that task: #5543, but again, it is something that we cannot implement before [email protected].

I agree that we should add more flexibility to our warning system: #5544. As a workaround, you can split your tsconfig.json and use the extend property: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#tsconfig-bases.

[bdwain]

@AndreyBelym but false is the typescript Default anyway. It shouldn’t make a difference to the end user if testcafe sets it or not, since if you set it to true it will override testcafe’s default. The only case where it matters is a case where testcafe is behaving incorrectly anyway (my case).

If it can’t be fixed until 2.0, Is there something we can do to fix this issue at least temporarily until then? Maybe an environment variable fo set that removes no implicit any? It can be removed in 2.0 when it stops setting that value?

Since things work overall, what are your thoughts on doing a release where you tell testcafe to use the typescript version your project uses? Basically implementing the ability to do what your test build did for real. I’d be happy to help with a pr if you’re open to it.

[AndreyBelym]

There is still a breaking change for users who enabled strict in their tsconfig.json and did not follow the noImplicitAny rule since it was disabled by TestCafe.

As a workaround, you can enable both "strict" and "noImpicitAny" in your tsconfig.json.

This issue is planned for the current development sprint. If everything goes as planned, this feature should be released in the next TestCafe version, which will be published shortly after the start of the next sprint. Please note that this estimate is not perfect, and the feature can be delayed or canceled.

[bdwain]

thanks!

[kirillgroshkov]

As of 2020-11-16 TypeScript 4.0 is still not supported, right?

ps: I bypassed this limitation by adding "resolutions" to my package.json like that:

  "//": "Kirill: this is to fix TestCafe compilation",
  "resolutions": {
    "typescript": "^4.0.5"
  },

[arubtsov]

@kirillgroshkov, Thank you for sharing your workaround with us. We will make it possible to specify a custom path to the typescript compiler in the next release.

[piotrl]

Proper workaround now:

set config path to root node_modules/typescript:
https://testcafe.io/documentation/402638/reference/configuration-file#compileroptions

In our case (as it's relative to node_modules/testcafe/

  "compilerOptions": {
    "typescript": {
      "customCompilerModulePath": "../typescript",

Old workaround won't work

The resolutions workaround doesn't work for us because typescript path seem to be hardcoded?

Cannot find module 'node_modules/testcafe/node_modules/typescript

with stacktrace:

Error: Unable to load the TypeScript compiler.
Cannot find module '/node_modules/testcafe/node_modules/typescript'

Require stack:
- /node_modules/testcafe/lib/compiler/test-file/formats/typescript/compiler.js
- /node_modules/testcafe/lib/compiler/compilers.js
- /node_modules/testcafe/lib/compiler/index.js
- /node_modules/testcafe/lib/runner/bootstrapper.js
- /node_modules/testcafe/lib/runner/index.js
- /node_modules/testcafe/lib/live/test-runner.js
- /node_modules/testcafe/lib/testcafe.js
- /node_modules/testcafe/lib/index.js
- /node_modules/testcafe/lib/cli/cli.js
- /node_modules/testcafe/lib/cli/index.js
- /node_modules/testcafe/bin/testcafe.js

[ghost91-]

Thanks @piotrl for explaining the workaround. That saved us a couple of hours trying to get it to work.

In our case, it isn't even our own test code that requires TypeScript 4 but one of our dependencies needs it for a type that we don't even use for the tests. But this still breaks the compilation when trying to execute the tests with testcafe.

It would be really nice if support for TypeScript 4 could be added. It feels weird to have to rely on this workaround...

[faizan-ali]

Thanks @piotrl - you saved me from hours lost getting to this solution myself

[helen-dikareva]

TestCafe v2.0 and up will include an up-to-date version of the TypeScript compiler (v4.7.4).