Open stephencweiss opened 3 years ago
If you need this right away, what you could try is Yarn Resolutions (npm doesn't have this yet, but it will in the next months - they will be called npm Overrides)
package.json
{
"resolutions": {
"**/tsdx/jest": "27.4.2",
"**/tsdx/ts-jest": "27.1.1"
}
}
Maybe you also need to upgrade the dependent libraries, such as @types/jest
and ts-jest
.
Let me share why I needed to upgrade jest independently. May be it helps someone who faces issue with tsdx + jest + enzyme setup.
There was a blocking issue "Javascript heap out of memory" in jest when running unit test cases through tsdx test
. This issue happened when enzyme was setup in the jest. One of the answer recommended to upgrade jest to 27.x version.
I followed the above comment to upgrade jest independently (thankyou @karlhorky) but another error was reported Error: Cannot find module 'babel-jest'.
I added it as yarn add -D babel-jest
and re-run the unit test cases tsdx test
and the blocking issue got fixed.
Current Behavior
TSDX comes with Jest v25. Jest v26 is currently in production and it looks like v27 is coming soon (with built in support for
jest-circus
). As far as I can tell there's no way to manually update the version of Jest independently of TSDX.Desired Behavior
A way to incrementally update dependencies of TSDX, e.g., Jest, without blowing away all of the other benefits of using TSDX.
Suggested Solution
I'm not sure how it would be accomplished, but if a library maintainer using TSDX could install the dependency (e.g., Jest v26) and then declare that dependency within the
tsdx.config.js
that would meet my needs well!Who does this impact? Who is this for?
It affects all library maintainers using TSDX, however, it's likely a more advanced use case as the defaults work most of the time. It also would help the maintainers of TSDX itself because there'd be an escape hatch that would allow maintainers to set their own dependencies without needing an update to TSDX.
Describe alternatives you've considered
I have not explored "ejecting" TSDX yet, but that seems like an alternative
Additional context