v2.1.4 FATAL ERROR: Reached heap limit Allocation failed

[simonasdev]

Hello again. Thanks for the 2.1.2 version fix.

Unfortunately, upgrading to 2.1.4 and running tsc presented an error on a whole different level:

<--- Last few GCs --->

[2053:0x5bd9060]    88488 ms: Scavenge 2027.0 (2073.3) -> 2023.9 (2074.5) MB, 19.1 / 0.0 ms  (average mu = 0.355, current mu = 0.179) allocation failure 
[2053:0x5bd9060]    88515 ms: Scavenge 2028.2 (2074.5) -> 2025.9 (2077.8) MB, 11.2 / 0.0 ms  (average mu = 0.355, current mu = 0.179) allocation failure 
[2053:0x5bd9060]    88542 ms: Scavenge 2031.4 (2077.8) -> 2028.8 (2096.0) MB, 10.2 / 0.0 ms  (average mu = 0.355, current mu = 0.179) allocation failure 


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb00e10 node::Abort() [/usr/local/bin/node]
 2: 0xa1823b node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0xcee09e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0xcee417 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0xea65d5  [/usr/local/bin/node]
 6: 0xeb5cad v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0xeb89ae v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 8: 0xe79b12 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 9: 0xe74[43](https://github.com/foroscom/foros-fe/runs/5145598143?check_suite_focus=true#step:5:43)c v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [/usr/local/bin/node]
10: 0xe7[45](https://github.com/foroscom/foros-fe/runs/5145598143?check_suite_focus=true#step:5:45)15 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/usr/local/bin/node]
11: 0x10dd41e v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate<v8::internal::Isolate>(v8::internal::Isolate*, int, v8::internal::AllocationType) [/usr/local/bin/node]
12: 0x10dd4d3 v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/usr/local/bin/node]
13: 0x11e9805 v8::internal::Runtime_MapGrow(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x15e7cf9  [/usr/local/bin/node]
Aborted (core dumped)
error Command failed with exit code 134.

Not really sure where to begin debugging, since no other output is present. The JS itself works as expected, but tsc runs forever and then OOMs. Do you have any idea what might have caused it?

[MathiasGilson]

yeah I actually have the same error on one of my project but I could not find what was causing it.

I managed to fix it by setting strict to true in my tsconfig.json :

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "lib": ["es5", "es6", "es2015", "es2016", "es2017", "es2018", "esnext"],
        "moduleResolution": "node",
        "esModuleInterop": true,
        "declaration": true,
        "jsx": "react",
        "allowJs": true,
        "resolveJsonModule": true,
        "sourceMap": true,
        "noImplicitAny": false,
        "strict": true,
        "experimentalDecorators": true,
        "allowSyntheticDefaultImports": true,
        "forceConsistentCasingInFileNames": false,
        "outDir": "./dist/",
        "baseUrl": "./",
        "typeRoots": ["./types", "./@types", "node_modules/@types"],
        "types": ["node"]
    },
    "exclude": ["./dist", "./node_modules/"]
}

[MathiasGilson]

maybe @Dudeonyx has an idea of where that issue comes from ?

[simonasdev]

well the strict was true for me to begin with. Seems like #44 could be suffering from the same culprit

[MathiasGilson]

yep, can you try rolling back to package version 2.1.2 ?

[simonasdev]

yeah, that is the last one that works for us, since 2.1.3 doesn't seem to be on npm

[bcucumber]

Hi I confirm that I also have the same issue. I've made a few tests and from >2.0.4 the typechecking and compilation seems to take a lot more time, and may sometimes throw OOM (even though that seems to happen 100% of the times on the latest versions).

I'm also using strict true like @MathiasGilson indicated before. This a small-sized project so I'm guessing it's not a matter of making a big use of the library as well. Do you think there is any way this could be debugged/benchmarked?

[MathiasGilson]

@Dudeonyx I think your typing is a bit excessive for tsc 😅 Can you try to remove some of the type checks? I've tried on my own but I end up removing most of it maybe there is a cleaner solution?

I updated the test to include extending a Tailwind Styled Component to trigger the heap limit allocation fail so you can test directly on your side.

I'll have to publish an updated version of the package with most of the typecheck removed so people's code compile. Can you please have a look?

Many thanks 🙏

[MathiasGilson]

Okay 2.1.7 was published, I removed most of the nested typing, the tests pass immediatly without the heap limit allocation fail so that should address this issue for now.

[bcucumber]

Hi @MathiasGilson thanks a lot, the ts problem has been fixed! I have noticed however that typings for custom props have been lost and bring problems when using no implicit any. For example:

const HelperText = tw.span<{ $error?: boolean }>`
  ${({ $error }) =>
    clsx({
      'text-text-500': !$error,
      'text-danger-500': $error,
    })}
`;

throws TS7031: Binding element '$error' implicitly has an 'any' type.

Thanks!

[mauriceackel]

@MathiasGilson It would be lovely if we could get a fix of the typing issue without the types being removed all together ❤️

[foxfirecodes]

any update on this? 100% happy to help out myself, I'm pretty experienced with TypeScript's typing system and doing weird wonky metaprogramming with it. do you know what part of the typings are actually the culprit for the performance issues? that would be a helpful starting point, otherwise happy to profile and debug this myself -- I really want to use this library but still be able to get typings!

[MathiasGilson]

Hello @rayzr522! I would love to get some help on that as I'm not the best when in comes to nested typing on typescript.

You can see on this commit that I removed a lot of typing for the tests to pass.

I'm afraid that I didn't understand which one was failing exactly but I tried to removed as few as possible with trial and errors.

Would appreciate if you would find some time to give it a look 😉