[4.5.0-beta] Crash with OOM

[Jack-Works]

Bug Report

<--- Last few GCs --->

[22928:00000293292C8690]    76794 ms: Mark-sweep 4042.1 (4136.7) -> 4029.8 (4140.2) MB, 3540.7 / 0.0 ms  (average mu = 0.427, current mu = 0.009) allocation failure scavenge might not succeed
[22928:00000293292C8690]    81105 ms: Mark-sweep 4045.9 (4140.2) -> 4034.0 (4144.2) MB, 4275.7 / 0.0 ms  (average mu = 0.249, current mu = 0.008) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF7D2C8FDCF v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112495
 2: 00007FF7D2C1EF86 DSA_meth_get_flags+65526
 3: 00007FF7D2C1FE3D node::OnFatalError+301
 4: 00007FF7D355167E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF7D353BB5D v8::SharedArrayBuffer::Externalize+781
 6: 00007FF7D33DF2AC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF7D33DC3E4 v8::internal::Heap::CollectGarbage+4244
 8: 00007FF7D33D9D60 v8::internal::Heap::AllocateExternalBackingStore+2000
 9: 00007FF7D33FE696 v8::internal::Factory::NewFillerObject+214
10: 00007FF7D3131965 v8::internal::DateCache::Weekday+1797
11: 00007FF7D35DF071 v8::internal::SetupIsolateDelegate::SetupHeap+494417

🔎 Search Terms

OOM 4.5.0-beta

🕗 Version & Regression Information

• This is a crash
• This changed between versions 4.4.4 and 4.5.0-beta

I can't create a small reproduce since it's an OOM problem.

Reproduction

1. Clone https://github.com/DimensionDev/Maskbook
2. Checkout to the ts-4.5 branch
3. Run pnpm install to install dependencies
4. Run pnpm run codegen
5. Wait for about 1.37 minutes on my machine, tsc crashes with OOM.

[andrewbranch]

Did you try with the nightly or just 4.5-beta?

[Jack-Works]

I just tried with 4.5-beta. Let me try nightly

[Jack-Works]

And I found there are much more reports of error TS2742: The inferred type of 'T' cannot be named without a reference to '../../../node_modules/async-call-rpc/out/full'. This is likely not portable. A type annotation is necessary.

[Jack-Works]

Yes, it no longer crashes with OOM now, but I have a package that uses"module": "nodenext",, it does not compiled to Node ESM, but CommonJS even with type: module in package.json. Why?

If you want to test, it's the packages/encryption folder.

[andrewbranch]

Humm. I don’t know about those two other things you noticed. Can you open new issues for those? Thanks!

[Jack-Works]

Yes, it no longer crashes with OOM now, but I have a package that uses"module": "nodenext",, it does not compiled to Node ESM, but CommonJS even with type: module in package.json. Why?

If you want to test, it's the packages/encryption folder.

For this problem, I found I also need to set moduleResolution to nodenext, module is not enough. But it isn't documented so it's quite hard to find.

[Jack-Works]

And I found there are much more reports of error TS2742: The inferred type of 'T' cannot be named without a reference to '../../../node_modules/async-call-rpc/out/full'. This is likely not portable. A type annotation is necessary.

Can you tell me what the rule is for this error? I think it's actually not a false positive but I don't know why it works in 4.4.4 and before. @andrewbranch

[andrewbranch]

The declaration emitter refuses to synthesize import paths containing /node_modules/, so that message means it that declaration emit is requiring it to print some type from that module, and it can't figure out a non-relative module specifier to get there. That library has an export map in their package.json that we are now respecting, and the export map is preventing us from being able to reach the out/full module. async-call-rpc needs to update their package.json to add "types" conditions into their export map. This is one of the main reasons why nodenext is experimental (#46452)—these kinds of ecosystem problems are going to take some time for package authors to fix, and most users are going to hit this like a brick wall in the meantime.