[Bug]: Upgrading to 29.2.5 leads to FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

[ortegarenzy]

Version

29.2.5

Steps to reproduce

Unable to shared private repository

Expected behavior

Same as in 29.2.3

Actual behavior

After upgrading our unit tests fail with the following message:

<--- Last few GCs --->

407 |   408 | [719:0x7022660] 45959 ms: Mark-Compact (reduce) 1533.1 (1563.3) -> 1532.1 (1563.5) MB, 1638.59 / 0.00 ms (average mu = 0.144, current mu = 0.014) allocation failure; scavenge might not succeed 409 |   410 |   411 | <--- JS stacktrace ---> 412 |   413 | FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 414 | ----- Native stack trace ----- 415 |   416 | 1: 0xb82c78 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node] 417 | 2: 0xeefa80 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node] 418 | 3: 0xeefd67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node] 419 | 4: 0x1101905 [node] 420 | 5: 0x1119788 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node] 421 | 6: 0x10ef8a1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node] 422 | 7: 0x10f0a35 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node] 423 | 8: 0x10ce086 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node] 424 | 9: 0x1529eb6 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node] 425 | 10: 0x1963ef6 [node] 426 | Aborted (core dumped) 427 | ·ELIFECYCLE· Test failed. See above for more details.

Debug log

Unable to share due to private repos

Additional context

No response

Environment

System:
    OS: Ubuntu 22.0
    CPU: 3 GB memory, 2 vCPUs
  Binaries:
    Node: v20.14.0
    npm: 10.7.0
  npmPackages:
    jest: 29.7.0

[ericcitaire]

We freezed the version of ts-jest in our projects because of this. This needs to be fixed or reverted please !

[ahnpnl]

@ericcitaire I couldn't investigate this without the help of a repo. Would you please share a reproduce repo for this?

Besides, you can switch to use isolatedModules: true, that is transpilation mode which doesn't burn memory, also preferable way in the future

[ericcitaire]

@ahnpnl I cannot share the code, as it's a large codebase from a private company project.

I've tried troubleshooting without success.

I also experimented with isolatedModules: true, which seems to work, but I received this warning:

ts-jest[config] (WARN) "isolatedModules" is deprecated and will be removed in v30.0.0. Please remove "isolatedModules" from your "ts-jest" transform options and enable "isolatedModules: true"

this warning is discouraging me from updating to a newer version.

[ahnpnl]

yes this is the intention that ts-jest will reuse same option from tsconfig to avoid lots of confusion about this option.

Besides, to stay inline with other transpilers, as well as reducing the overhead in memory, isolatedModules in recommended 😇

[ahnpnl]

Btw, the warning message means to ask users to use isolatedModules: true in their tsconfig. It doesn't mean about the whole codes behind it will be removed. If that is misunderstanding, I'll correct the message to be clearer.

[deanc]

Just want to add to this, we have what I'd say is a medium-sized repository at my client and our whole repo is in typescript. Renovate bot bumped ts-jest in a PR from 29.3.3 > 29.4.1 and memory usage for one of our suites in the monorepo jumped significantly:

Before

> jest --clearCache && /usr/bin/time -v jest
Test Suites: 50 passed, 50 total
Tests:       1140 passed, 1140 total
Snapshots:   70 passed, 70 total
Time:        54.555 s
<SNIP>
Maximum resident set size (kbytes): 2363136

After

> jest --clearCache && /usr/bin/time -v jest
Test Suites: 50 passed, 50 total
Tests:       1140 passed, 1140 total
Snapshots:   70 passed, 70 total
Time:        64.13 s
<SNIP>
Maximum resident set size (kbytes): 3056028

This is around a 30% bump in maximum memory usage just by bumping one dependency (nothing else) in our project.