jest-transform: testRegex value shows empty object instead of RegExp object

[ahnpnl]

🐛 Bug Report

Custom transformer receives jest config string via getCacheKey. In ts-jest recently we rely on testRegex to do some logic. However, the value of testRegex which is passed to transformer is unusable. Instead of receiving the real value of the regex, transformer receives it as [{}]

Related to kulshekhar/ts-jest#1509

To Reproduce

Steps to reproduce the behavior:

• Clone the repo and switch to branch test-regex-transformer .
• Install dependencies with yarn, run yarn test and see the exception
• Trace the exception back to getCacheKey and inspect jestConfigStr, observe the value in the picture below (red circle)
  
• Trace back to ScriptTransformer.js constructor, observe the input value of config is
  
• The value after this line https://github.com/facebook/jest/blob/2edd5c4724cfadb944a6a233a7ad8fb5a3e05996/packages/jest-transform/src/ScriptTransformer.ts#L72 becomes [{}] and it is unusable.

Expected behavior

testRegex value which is passed to transformer should be usable and retain its original value.

Link to repl or repo (highly encouraged)

https://github.com/ahnpnl/ts-jest-babel-example/tree/test-regex-transformer

envinfo

System:
    OS: macOS 10.15.4
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Binaries:
    Node: 12.16.1 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
  npmPackages:
    jest: ^25.2.7 => 25.2.7 

[ahnpnl]

The workaround transformer can do is don’t use the value from jestConfig string but use the value from the last parameter which is an object and it contains the original config object

[SimenB]

Yeah, the string is just meant to be used for cache busting purposes (i.e. "any config change should bust the cache") - if you want to actually read any value you should use the last parameter. We should fix the serialization though - I think we currently just do essentially JSON.stringify. Since we know the shape, it might be that something like https://github.com/fastify/fast-json-stringify is a good idea. Or maybe https://github.com/storybookjs/telejson

[ahnpnl]

Since ts-jest is using its own stringified version cacheKey based on config, I think it's safe to ignore this string config version from getCacheKey ? or what do you suggest for us regarding to the usage with string config ?

[ahnpnl]

Yeah, the string is just meant to be used for cache busting purposes (i.e. "any config change should bust the cache") - if you want to actually read any value you should use the last parameter. We should fix the serialization though - I think we currently just do essentially JSON.stringify. Since we know the shape, it might be that something like https://github.com/fastify/fast-json-stringify is a good idea. Or maybe https://github.com/storybookjs/telejson

I saw internal jest uses fast-json-stable-stringify (ts-jest also uses this), so I guess jest will switch to either fast-json-stringify or telejson ?

[SimenB]

or what do you suggest for us regarding to the usage with string config ?

Yeah, feel free to ignore it if you want - it's just there as a convenience

[ahnpnl]

ping @SimenB , we observe another issue related to testRegex, this time is when using ts-jest with babel. The same repo. The reproduce steps are:

• Run test with yarn test and observe test fail
• Clear cache
• Delete foo.spec.js
• Run test again and observe test pass

When debugging ts-jest here, I noticed that jest passed to ts-jest a wrong value of testRegex when foo.spec.js is in the project and vice versa. In detail:

• When foo.spec.js is in the project, testRegex has the value as [ {} ]
• When foo.spec.js is not in the project, testRegex has the value as instanceof RegExp

Currently ts-jest heavily relies on testRegex and testMatch to detect a file is a test file or not. Is there a workaround for it ?

Related to kulshekhar/ts-jest#1552

[SimenB]

I'm guessing, without running the reproduction, that this is due to workers (which will get empty object) and running in band (which will get the regexp). I'm currently away from a computer, so I can't verify

[ahnpnl]

hmm, I thought workers share the same config object which shouldn't be different. Or before creating ScriptTransformer instance in each worker, the config object has been modified somehow ?

Is there an alternative way I can detect if that is a test file besides relying on testRegex or testMatch ?

UPDATE: You were right. At this point https://github.com/facebook/jest/blob/fa4cbbf87cb3c97fe44f1fee30663715a9dbba71/packages/jest-runner/src/index.ts#L120
The config is still correct. However when sending messages to worker with stringified version, it causes the bug imo.

[ahnpnl]

also seem to be strange that only occurs when there is a js next to that ts. I have a repo which only contains ts and no issues in parallel mode.