[V4] custom jest transforms (e.g. ts-jest) no longer working

[jrr]

Tried out 4.0.0-next.98 today (coming from 3.4.3) in a medium-sized typescript monorepo. Our app builds and runs just fine.

Unfortunately some of our Jest tests broke. It looks like ts-jest is no longer getting used. Previously (with CRA3) we were able to specify a transform in the jest section of package.json like this:

    "transform": {
      "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/ts-jest"
    },

This allowed us to use TypeScript features not supported by Babel (like emitDecoratorMetadata for TypeORM).

Looking at the v3.4.1...master diff, I'm not sure what broke it. Perhaps something about Jest 26?

I will try to produce a repro repo when I can.

Repro steps in short:

• npx create-react-app --template typescript my-react-app
• add a const enum to the test (not supported by babel)
• yarn test (see it fail)
• install ts-jest and add the transform line above
• yarn test (see it pass)
• update to react-scripts 4.0.0-next.98, see yarn test break again.

Example repo here: https://github.com/jrr/cra-4-ts-jest-issue

[jrr]

I tried this today with the 4.0 release and it's still broken. Repro repo updated:

https://github.com/jrr/cra-4-ts-jest-issue

[gvanderclay]

I'm on the same project as @jrr and I discovered that passing in the transform property as a CLI argument can be used as a workaround

[gvanderclay]

Changing the transform key to match the regex in createJestConfig for babel-jest fixes this.

I.E change:

"transform": {
  "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/ts-jest"
},

to

"transform": {
  "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
},

[jrr]

I bet it was this PR, which changed the regex between CRA 3 and 4:

https://github.com/facebook/create-react-app/pull/8768/files

The overridden transform object is merged with CRA's default:

https://github.com/facebook/create-react-app/blob/027b03ba8d689e619a912ed0d72c3a11ef22ac2f/packages/react-scripts/scripts/utils/createJestConfig.js#L97-L107

So, practically, this means you can change the transform applied to CRA's regex, but you can't change the regex.

It also means your config override can silently break if upstream's regex changes. 😐

[jrr]

Closing as its no longer affecting us. To anyone stumbling upon the thread: if you're using the "jest" configuration key in package.json, dig in to react-script's source to understand what it's doing, and don't be surprised if your configuration breaks during upgrades.

[diegooliveirasanchez]

I've been trying to get this to work for 2 days but found no success yet.

I have this property in package.json

 "jest": {
    "transform": {
      "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
    }
  }

With package versions:

"react-scripts": "4.0.3",
"ts-jest": "^26.5.2",

The key "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$" matches the one in createJestConfig.js for these versions, but it still doesn't work.

My script for testing in package.json is:

"test": "react-scripts test"

What am I doing wrong?

[diegooliveirasanchez]

I've been trying to get this to work for 2 days but found no success yet.

I have this property in package.json

 "jest": {
    "transform": {
      "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
    }
  }

With package versions:

"react-scripts": "4.0.3",
"ts-jest": "^26.5.2",

The key "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$" matches the one in createJestConfig.js for these versions, but it still doesn't work.

My script for testing in package.json is:

"test": "react-scripts test"

What am I doing wrong?

I think I figured it out. It seems the transform property was not at fault actually and that my error was somewhere else. I set "resetMocks": false, in my jest configuration in package.json and this solved my problem.

I was getting some cryptic error messages, that's why I couldn't identify the root cause accurately. It seems that since v4 of react-scripts, the resetMocks flag is set to true by default, which is different behaviour than in the previous version.

If you recently upgraded versions and a bunch of your tests are failing for mysterious reasons, I recommend testing if this flag is causing the issue.