[core] typescript-next pipeline runs out of memory

[aarongarciah]

We run TypeScript tests against typescript@next nightly. The pipeline (typescript-next) fails in the "Tests TypeScript definitions" step with the following error:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Example failure: https://app.circleci.com/pipelines/github/mui/material-ui/136928/workflows/414a50d8-8d10-4e80-b16e-bd1dbc7c6660/jobs/738223?invite=true#step-107-200

Context: the pipeline is all green because we intentionally ignore failures. See https://github.com/mui/material-ui/blob/next/.circleci/config.yml#L363-L371

Search keywords: TypeScript, ci, test

[sjungling]

We're seeing a similar error on builds of a private repo on GitHub Actions (ubuntu-latest) for a branch that is attempting to upgrade our MUI packages and code to 6.0.0.

Typescript Version 5.5.4
Node version: 20.17.1

Locally, I am not seeing this error (MBP M1, 16GB, node v20.17.0).

What appears to be a workaround for the moment is increase the max-old-space-size to 4Gb in our Actions workflow.

        env:
          NODE_OPTIONS: --max-old-space-size=4096

Error:

> tsc


<--- Last few GCs --->

[1831:0x62572c0]    42801 ms: Scavenge (reduce) 2043.5 (2082.8) -> 2043.0 (2083.1) MB, 1.57 / 0.00 ms  (average mu = 0.136, current mu = 0.004) allocation failure; 
[1831:0x62572c0]    44010 ms: Mark-Compact (reduce) 2043.7 (2083.1) -> 2043.0 (2083.3) MB, 1206.25 / 0.00 ms  (average mu = 0.116, current mu = 0.096) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xb82d33 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0xef0c50 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0xef0f37 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x1102ad5  [node]
 5: 0x1103064 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
 6: 0x1119f54 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [node]
 7: 0x111a76c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 8: 0x10f0a71 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0x10f1c05 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0x10ce326 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
11: 0x10bfa9c v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
12: 0x10bfc04 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
13: 0x13ef9bd v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate(v8::internal::Isolate*, int, v8::internal::AllocationType) [node]
14: 0x13efa63 v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashMap>, int) [node]
15: 0x1520673 v8::internal::Runtime_MapGrow(int, unsigned long*, v8::internal::Isolate*) [node]
16: 0x7f20e0e99ef6 
Aborted (core dumped)

[Vagizova]

we have exactly the same. I dont want to increase the max-old-space-size because it wont fix the issue itself. Any Ideas? @aarongarciah ?

we use:

"@mui/material": "^6.1.3",
"@mui/x-data-grid-premium": "^7.20.0",
"@emotion/react": "^11.13.3",
"@emotion/styled": "^11.13.0"

Actually, we are still at the stage of choosing a library for the table. We haven't bought a license key yet, so I can't create a premium issue, and I choose to just write to the existing one. This problem is one of the most crucial for us. Let me know what you think about it