Heap out of memory memoryLimit issue in ForkTsCheckerWebpackPlugin
#271
Comments
|
Could be worth upping your https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/master/README.md#options |
|
@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. |
|
@johnnyreilly I also made a simple repo with what I used. It works just fine. However as I add more reducers/Actions the application then crashes with the same error. |
|
@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. |
|
@phryneas electron-userland/electron-webpack#280 While using |
|
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 PS: just invoking PPS: |
|
I'm considering a |
|
Apart from |
|
Another thing that just came up in a conversation with colleague: you should not import from Do maybe that helps PS: the same thing, albeit with a lower impact applies to |
|
Also, you might consider downgrading to TS 3.3: microsoft/TypeScript#30663 |
|
I just upgraded to the new version today and I have the same problem. I tried to increase the memory, and roll back the ts version, there is no way to solve it. |
|
Could you please specify, which packages exactly you updated and from which to which version?
|
|
I am testing. When I upgraded from 0.5.2 to the latest version. Originally it took 11s, and it became 13s after the upgrade. |
|
Node12 There will be no memory explosion problems. I tried what it was caused. |
|
This is a magical problem, I also encountered, I tried to roll back the package, but it will also trigger the problem of insufficient memory. And I can compile smoothly on another computer. |
|
|
|
Exactly. That's why I'm asking about your TS version - 3.4 seems to have some problems regarding performance.
…```tsc --noEmit```
I use this script to get the same result, should it be the error caused
by typescript?
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
|
|
3.3.x If properly installed, it will not cause memory leaks. Originally I may not have correctly rolled back the typescript version. Type checking can be done when So I think it might be a typescript 3.4.x and 3.5.x error. Because I run |
|
It should be the problem of this. use |
|
I tried all versions after 3.3.400 and they all had the same issue. So sticking with TS 3.3.4 for now |
|
Working flawlessly for me after upping the config-overrides.js Discovered my confusion by inspecting the command line via |
|
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. |
|
Hi, I also have a memory issue on type checking, since I upgraded one of my project lib ( Note that When I try a build, it takes like 5min then fails with this error stack: 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 ? |
|
@Chnapy I'm having the same issue and it's working |
|
Did someone managed to fix this issue? |
|
Could you try fork-ts-checker-webpack-plugin@alpha? I've published a new version which potentially could resolve this issue :) |
|
I unfortunately am unable to utilize This thread did help me however in setting the memory limit and compiling in isolation: ... which helped me determine that I have a memory problem regardless of the memory limit: 2GB, 4GB, 8GB - same result. So to anyone trying to override the memory limit, investigate the cause rather than to suppress the symptoms. |
|
@jorisw have you found a solution to this? Getting the same error |
|
In my case, I was importing style object definitions targeting ThemeUI, each typed as a 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 As you can see, a pretty specific use case, so our problems are likely to be very different. |
|
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: system-ui/theme-ui#1162 (reply in thread) |
For anyone seeing this issue in cases where it doesn't seem related to a specific commit (i.e. roll-back doesn't work), I would like to highlight this solution. Due to some unrelated permissions issues I had temporarily made a copy of node_modules which led to this out-of-memory issue. |
Thank you for sharing this solution. It worked for me. |
Thanks @fc, this solved the problem. |
|
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; |
|
@ChuckJonas This is most likely a TypeScript issue :) |
Hi @phryneas This is interesting, can you please explain (or link) the difference ? I'm using the latter in my project to reduce the number of lines of imports, but consider changing for the former if it helps reducing the RAM consumption. |
|
@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. |
|
This helped me, thanks. I was trying to figure out why it kept crashing, and didn't think about mui. Of course! |
Thank you very much for this @fc ! Thanks to me getting around too late to Anyways, the presence of that folder caused "issues checking in progress..." to take a minute or two and then OOM, whereas usually it takes a few seconds and does not OOM. I don't know how long it would have taken me to find the issue without @fc's comment. How could one get |
|
Hey guys, has anyone been able to fix the type checking memory leak issue? |
|
Seems to be the problem issuer is not that plugin or typescript itself. For me the problem issuer was |
Wrestled with this issue for quite some time in a Create React App TypeScript project with MUI. Seeing you reference import { LoadingButtonProps } from '@mui/lab';
type ComponentProps = LoadingButtonProps & {
sx?: SxProps; // This was the problem!
}; |
|
@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 The solution was to import 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 |
|
Just in case it helps someone: |
and others
Current behavior
Upgraded to start using electron-webpack and upgraded all our packages to newer versions.
Expected behavior
Typescript and webpack should compile code
Steps to reproduce the issue
use electron webpack with typescript?
Issue reproduction repository
Environment
package.json]in node modules under /electron-webpack-ts/package.json
fork-ts-checker-webpack-plugin: 0.5.2
package.json]typescript: 3.4.5
package.json]"tslint": "^5.14.0",
package.json]"webpack": "4.28.4"
Ubuntu 18.04
Error from running electron-webpack dev
The text was updated successfully, but these errors were encountered: