Set Babel dependancies to a certain version, not point to the latest version

[gforepsly]

What is your Scenario?

When @babel/plugin-transform-runtime version 7.23.4 came out, we couldn't run testcafe tests because of some weird runtime error. The error was:

TypeError: [BABEL] /opt/TeamCityAgent/work/47767e15a36475f9/node_modules/@babel/plugin-transform-runtime/lib/babel-7/polyfills.cjs: _index2.createPolyfillPlugins is not a function (While processing: "base$0") (While processing: "base$0")
08:45:25 at Object.

Basically it pointed to 1 of our helper files which we import into tests, which imports axios. It's not possible to reproduce when trying a new, fresh testcafe project, so I guess it's something deeper in our structure.
But, hardcoding version of @babel/plugin-transform-runtime version to version 7.22.15 in our package.json as a dev devependency solved the issue.

I managed to check the package-lock.json and noticed testcafe uses latest version when you run npm i testcafe as a dependancy ("@babel/plugin-transform-runtime": "^7.12.1").
Is it possible to hardcode only 1 working version as a testcafe dependancy so we don't run into this kind of issues in the future?

What is the Current behavior?

When Babel package gets new version, there is a possibility that running testscafe stops working in certain scenarios because testcafe uses latest dependacy of babel npm packages

What is the Expected behavior?

It should be better to use only 1 version and update to another when needed.

What is the public URL of the test page? (attach your complete example)

No public URL, simply a comment on the dependandcies policy

What is your TestCafe test code?

Explained in the first step

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

1. Basically just run the test in certain conditions and the code never gets compiled properly

TestCafe version

3.4.0

Node.js version

18.18.0

Command-line arguments

testcafe testName.ts

Browser name(s) and version(s)

chrome latest

Platform(s) and version(s)

MacOS Ventura 13.1 or any Windows machine

Other

No response

[github-actions]

Thank you for submitting a bug report. We would love to help you investigate the issue. Please share a simple code example that reliably reproduces the bug. For more information, read the following article: How To Create a Minimal Working Example When You Submit an Issue. We look forward to your response.

[mokone91]

same issue with latest @babel/plugin-transform-runtime

[gforepsly]

same issue with latest @babel/plugin-transform-runtime

Do you maybe have some simple code example to replicate this? I can't share my whole complex repo for this one, too much sensitive data.

[ayemelyanenko-chegg]

I'm also seeing this but can't share as my repository is private

[philga7]

We're seeing the exact same issue as OP. To be honest, I'm not sure why a simple code example is needed to replicate this. The idea is if one's application is itself using an axios dependency (presumably for API work), then both the application and TestCafe are likely going to end up clashing over version differences.

This is an installation issue, and I'd ask that the TestCafe devs seriously take a look at why there is such a dependency here. For us, it's bad enough that we can't use native mode for testing after the move to CDP (itself a welcome call otherwise) because of apparent contingencies with the legacy engine. This honestly makes us wonder if we're going to be able to upgrade TestCafe in the future or if we have to look at another framework.

I know I'm venting a bit here, however there is definitely a level of frustration in hitting so many speedbumps with this framework. I've been around TestCafe for a few years and know its benefits. I'm hoping that the framework can get back to that soon.

Thanks!

[ayemelyanenko-chegg]

For the TestCafe dev team - I managed to reproduce the issue.

Please clone this sample repository,
run yarn install
and then from root, run
yarn testcafe chrome sampleTest.ts

And this error will show up

[github-actions]

We appreciate you taking the time to share information about this issue. We reproduced the bug and added this ticket to our internal task queue. We'll update this thread once we have news.

[PavelMor25]

Hello,

While we are investigating the issue, you can override the version of the @babel/plugin-transform-runtime package.
Add the overrides section to the package.json file if you are using npm or the resolutions section if you are using yarn:

{
  "resolutions": {
    "@babel/plugin-transform-runtime": "7.23.3"
  },
  "overrides": {
    "@babel/plugin-transform-runtime": "7.23.3"
  },
}

[Humberto1945]

Hi, I am also running into this issue and adding the overrides section to the package.json file did not help me.

[gforepsly]

Hi, I am also running into this issue and adding the overrides section to the package.json file did not help me.

Hi!
Add "@babel/plugin-transform-runtime": "7.22.15" to dev dependancy in your package.json, then delete package-lock-json and node_modules. Then run "npm i" to install the packages again and it should work. that is our current workaround.

[Humberto1945]

Hi, Thanks for the advice! Looks like I am still having the issue though. Did you remove the override?

[gforepsly]

Hi, Thanks for the advice! Looks like I am still having the issue though. Did you remove the override?

We did not, we still have the override like I explained we have it. Fortunately everything works fine for us. I hope the Testcafe team will fix it soon, this is a nasty issue.

[Humberto1945]

Very nasty issue not being able to run tests. I hope they are able to fix this soon as well.

[Humberto1945]

Just reverted to 3.3.0

[github-actions]

Release v3.5.0-rc.1 addresses this.

[github-actions]

Release v3.5.0-rc.1 addresses this.