chore: bump jest to version 29

[jean-smaug]

Close #12444

[jean-smaug]

Returning string isn't allowed anymore with v28

https://jestjs.io/docs/upgrading-to-jest28#transformer

[jean-smaug]

Needs to installed separately from jest
https://jestjs.io/fr/docs/upgrading-to-jest28#jsdom

[shahmirn]

Jest 28 has "issues" with, at least, the uuid and nanoid packages, based on:

https://jestjs.io/docs/upgrading-to-jest28#packagejson-exports

In my company's codebase, we ran into the same issue with the @hookform/resolvers package also

CRA / this PR would ideally handle this, and also expose some configuration to allow additional packages to be included in this "list"

[jean-smaug]

Jest 28 has "issues" with, at least, the uuid and nanoid packages, based on:

https://jestjs.io/docs/upgrading-to-jest28#packagejson-exports

In my company's codebase, we ran into the same issue with the @hookform/resolvers package also

CRA / this PR would ideally handle this, and also expose some configuration to allow additional packages to be included in this "list"

👋

The case that you describe can surely be solved by an overriding tool such as Craco.

IMHO it's not the responsibility of CRA to handle specific related to external packages. Because it's impossible to determine all packages that will need this specific config.
And adding this kind of feature, could be a first step in allowing CRA to be overridable, which is not something bad. But it's not something that I can decide.
At least, it should be mentioned in the documentation as a "known issue" 🤷‍♂️

@mrmckeb what do you think ?

[shahmirn]

I feel like nanoid and uuid should definitely be handled out of the box, as they're super-popular packages and a bunch of people will run into the issue.

For others, it may be worth exposing a new ENV variable that can be set, similar to others mentioned at

https://create-react-app.dev/docs/advanced-configuration

[jean-smaug]

I feel like nanoid and uuid should definitely be handled out of the box, as they're super-popular packages and a bunch of people will run into the issue.

For others, it may be worth exposing a new ENV variable that can be set, similar to others mentioned at

https://create-react-app.dev/docs/advanced-configuration

Seems a good answer to your demand 🤷‍♂️
https://jestjs.io/docs/upgrading-to-jest29#jsdom-upgrade

I'll do the upgrade later, but this PR will finally be a bump to v29 of jest 😄

[lnhrdt]

Hey @iansu I did some digging and saw that you were the one that merged the PR the last time Jest was upgraded in CRA. Any chance you could help move this along and into a new release? Or can you suggest another way to proceed?

[arkosarkar343]

Can we please merge this PR? In my project there are 1244 tests and it takes around 20mins to run. Upgrading jest to 29 will help us use sharding and I am sure it will reduce significant amount of time.

[ghalestrilo]

Can we please merge this? Facing a similar situation to what @arkosarkar343 described

[gauravshah27]

Can we get someone to merge this PR - we are facing memory issues on Node.js 16 and Node.js 18 and here are some of the issues that are we are seeing:

• When a process runs out of memory worker does not exit correctly and spins indefinitely (claimed to be fixed by 29.0.0-alpha.1
• Need to leverage workerIdleMemoryLimit option that can fix worker memory leaks for Node.js version >= 16.11.0 and recycles child workers as needed (claimed to be fixed by 29.0.0-alpha.3. Here is the github link for this specific comment - [Bug]: Memory consumption issues on Node JS 16.11.0+ jestjs/jest#11956 (comment)

This is preventing us from using Node.js 16 and 18 and we have to keep using the Node.js 14 version which is end-of-life and thus increases the security risk.

Can any maintainer that has context on this PR comment and provide a timeline on when this is going to be merged ??

It would also be equally helpful to let us know if this is giong to move forward or no - given the direction that React is going in where they are recommending the use of Next.js / Remix for developing applications.

It would be great if we can get a release from CRA enabling jest 29 so that we can move to the latest LTS versions of Node.js without running into issues that we are seeing already in terms of memory usage of jest workers.

[wyardley]

Maybe see comments in
#13066
we are looking at moving to Vite in the short term, while exploring longer term options.