fork-ts-checker-webpack-plugin: Heap out of memory `memoryLimit` issue in ForkTsCheckerWebpackPlugin

Hey guys, has anyone been able to fix the type checking memory leak issue?

I’m considering a skipLibCheck tattoo. Or I would be if I wasn’t already filled with regret about the noImplicitAny one I got one drunken night in 2014

It should be the problem of this. https://github.com/microsoft/TypeScript/issues/31227

use npm i typescript@3.3.4000 to solve the problem

Could be worth upping your memoryLimit

https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/master/README.md#options

In my case, I was importing style object definitions targeting ThemeUI, each typed as a SxStyleProp, then doing composition with the imported objects to create different styles for different states, like so:

export const someStyle: SxStyleProp {
   maxWidth: 300,
}

import {
  someStyle
} from './styles'

const manyStyles: SxStyleProp = {
  ...someStyle,
  ...(isActive ? someMoreStyles : {}),
  // ...
}

Apparently importing and composing these typed objects made the typechecker go into a memory leak of some sort. Removing the : SxStyleProp typing from each of my exported styles in styles.ts, made the problem go away.

As you can see, a pretty specific use case, so our problems are likely to be very different.

Wrestled with this issue for quite some time in a Create React App TypeScript project with MUI. Seeing you reference SxProps made me scan my project for places I was including it. Sure enough, I defined a Type that extended a MUI component and defined an optional sx property (probably wrote the Type before making it extend the MUI component). Removing the override solved the problem 😄 Thank you @jorisw

import { LoadingButtonProps } from '@mui/lab';

type ComponentProps = LoadingButtonProps & {
    sx?: SxProps; // This was the problem!
};

I had made a copy of the node_modules folder in the same directory that led to me getting this error. Deleting the copied folder resolved it for me.

@the-rpc we were having a similar issue with a CRA with Typescript project using MUI v6!!

You helped us pin the same issue we were experiencing when executing react-scripts build: importing SxProps directly from import { SxProps } from '@mui/system'; or even import { SxProps } from '@mui/materials/styles'; resulted in a memory leak!

The solution was to import sx’s type directly from the MUI component, for instance SelectProps['sx'], ButtonProps['sx'] etc… 😅

I hope MUI can fix the way they export their types…

This fixed an issue for us on a TypeScript project using MUI as well. The memory issue is gone after removing the SxProps direct import.

@Chnapy I’m having the same issue I have turned off

"strict": false,
"strictNullChecks": false,
"strictPropertyInitialization": false,

and it’s working using typescript 3.7.5 and fork-ts-checker-webpack-plugin 4.0.3

@the-rpc we were having a similar issue with a CRA with Typescript project using MUI v6!!

You helped us pin the same issue we were experiencing when executing react-scripts build: importing SxProps directly from import { SxProps } from '@mui/system'; or even import { SxProps } from '@mui/materials/styles'; resulted in a memory leak!

The solution was to import sx’s type directly from the MUI component, for instance SelectProps['sx'], ButtonProps['sx'] etc… 😅

I hope MUI can fix the way they export their types…

Did someone managed to fix this issue?

Working flawlessly for me after upping the memoryLimit on the plugin itself via React App Rewired. (Because it forks, adjusting memory settings on the parent process don’t help.)

config-overrides.js https://gist.github.com/edwingustafson/ee786fe26c6a7fae394321a892698f64

Discovered my confusion by inspecting the command line via ps wwwaux on my development box: it showed the plugin’s process getting the default memory limit as a command line option.

Another thing that just came up in a conversation with colleague: you should not import from @material-ui/icons directly.

Do import Close from "@material-ui/icons/Close"; instead of import {Close} from '@material-ui/icons'

maybe that helps

PS: the same thing, albeit with a lower impact applies to @material-ui/core

First thing I am noticing: you are including all .d.ts in node_modules which will include these in the typecheck - usually those should be automatically included as they are the default value of typeRoots. Does everything keep working when you remove them from include in the tsconfig.json? If not, try using compilerOptions.typeRoots instead of include for those.

PS: just invoking tsc --noEmit takes about 80 seconds on my system. That project has less than 100 files, that should take at most 5 seconds. Something is very off there, but it has nothing to do with fork-ts-checker-webpack-plugin

PPS: tsc --noEmit --skipLibCheck is down to 50 seconds. That’s a first step.

Hi,

I also have a memory issue on type checking, since I upgraded one of my project lib (react-scripts from 2.1 to 3.X (tried with 3.0.1, 3.2.0, 3.3.0).

Note that react-scripts uses fork-ts-checker-webpack-plugin 3.1.0 in its webpack config. I use typescript 3.3.3 (also tried with 3.7.5).

When I try a build, it takes like 5min then fails with this error stack:

<--- Last few GCs --->

[62388:0x10280e000]   171064 ms: Scavenge 2017.5 (2093.5) -> 2002.2 (2095.0) MB, 6.5 / 0.0 ms  (average mu = 0.262, current mu = 0.223) allocation failure
[62388:0x10280e000]   171096 ms: Scavenge 2017.7 (2095.0) -> 2002.4 (2097.5) MB, 6.3 / 0.0 ms  (average mu = 0.262, current mu = 0.223) allocation failure
[62388:0x10280e000]   171124 ms: Scavenge 2017.9 (2097.5) -> 2002.6 (2099.5) MB, 7.3 / 0.0 ms  (average mu = 0.262, current mu = 0.223) allocation failure


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x1bf3a39dbe3d]
Security context: 0x112bbff9e6e9 <JSObject>
    1: trySymbolTable(aka trySymbolTable) [0x112b05636ab1] [/Users/b046lj/Projects/afds_ext/afds-webapp/frontend/node_modules/typescript/lib/typescript.js:~33453] [pc=0x1bf3a4be076a](this=0x112bfd8826f1 <undefined>,symbols=0x112bf143fd71 <Map map = 0x112b4f684359>,ignoreQualification=0x112bfd8826f1 <undefined>)
    2: getAccessibleSymbolChainFromSymbolTable(...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 5: 0x100589845 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 6: 0x1005856ef v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 7: 0x1005838c4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 8: 0x10059015c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
 9: 0x1005901df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
10: 0x10055fb24 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
11: 0x1007e7e04 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/b046lj/.nvm/versions/node/v10.16.3/bin/node]
12: 0x1bf3a39dbe3d

I tried to increase the memory limit to 9000 as a test, in this case the process takes like 10min before failing (the node process takes until 9go of memory…).

There is an issue with my project types, but I have no idea where to check, the error message doesn’t help me at all.

There is a way to add logs during type checking, or anything else that can help me to find the issue root cause ? Thanks

Seems to be the problem issuer is not that plugin or typescript itself.

For me the problem issuer was mongodb package < v5 with its declarations , upgrade to > v5 solves the problem. You can also find issuer by paste each of your sources path (nested too) in tsconfig.js’s include field, just restart app and wait for stuck. It took only 5 mins to find bad dependency in my project.

@Mikado68 this issue is 3 years old, no idea if that is still relevant. By then it was the difference between importing all icons (that file was non-treeshakable) and only one.

@ChuckJonas This is most likely a TypeScript issue 😃

using material ui and CRA, I run out of memory whenever I use styled components:

import Typography from '@mui/material/Typography';
import { styled } from '@mui/system';

const UnderlinedText = styled(Typography)({
    marginTop: '10px',
    color: 'rgba(0, 105, 165, 1)',
    textDecoration: 'underline',
    marginBottom: '15px',
});

export default UnderlinedText;

Turns out the problem I was having, was related to TypeScript being bad at handling use of the spread (…) operator on objects that have union types. Using Object.assign() instead fixes it.

Discussion: https://github.com/system-ui/theme-ui/discussions/1162#discussioncomment-59480

In my case, I was importing style object definitions targeting ThemeUI, each typed as a SxStyleProp, then doing composition with the imported objects to create different styles for different states, like so:

export const someStyle: SxStyleProp {
   maxWidth: 300,
}

import {
  someStyle
} from './styles'

const manyStyles: SxStyleProp = {
  ...someStyle,
  ...(isActive ? someMoreStyles : {}),
  // ...
}

Apparently importing and composing these typed objects made the typechecker go into a memory leak of some sort. Removing the : SxStyleProp typing from each of my exported styles in styles.ts, made the problem go away.

As you can see, a pretty specific use case, so our problems are likely to be very different.

@marcusjwhelan could you share that repro so I could take a peek? (No guarantees though.) Sometimes there are just TS patterns that lead to a looot of memory consumption.

@johnnyreilly I moved the memory to 8192 but still failed with the same error just takes a little longer. I believe after talking to someone from electron-webpack that my issue could be a memory leak having to do with Typescript itself.