FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory #67
Comments
|
This is not very useful I think we need more info to understand this issue. The simplest advise I can give you is to extend the limits for your node process on the OS level, you can use google or chatgpt to find info how to do that in your case. Also if it still will be failing I think you should try to run eslint in debug/verbose mode so maybe we will see some more usefull info before it crashes as those logs are practically useless apart from seeing that your node process limit is 4GB (which is low btw). |
gund
added
the
needs more info
|
Sorry, from the info in issue template didn't know if the issue will be looked at - hence didn't bother with much info. Thanks for looking into this. Here is more info {
"ignorePatterns": [
"node_modules",
"stencil-generated",
"dist",
"www",
"!.storybook"
],
"env": {
"jest": true,
"es6": true
},
"parserOptions": {
"ecmaVersion": 2020,
"sourceType": "module"
},
"overrides": [
{
"files": ["**/*.ts", "**/*.tsx"],
"parser": "@typescript-eslint/parser",
"plugins": ["@typescript-eslint", "deprecation"],
"extends": ["./node_modules/gts"],
"parserOptions": {
"jsxPragma": "h",
"project": "./tsconfig.json"
},
"rules": {
"deprecation/deprecation": "warn"
}
}
],
"root": true
}Increasing heap size to
My branch: https://github.com/coveo/ui-kit/tree/KIT-2592_eslint_plugin_deprecation Running eslint with |
|
If it helps, here's a list of rules run on my repo with relative timing perf: "eslint": "^8.45.0",
"eslint-plugin-deprecation": "^1.4.1"
|
|
Thanks for posting more details on this! Regarding the execution time of this rule we already have an issue opened but I'm afraid there is not much we can do judging by this comment a TS API that's used is simply expensive so it's unavoidable and will take time to run this rule on the whole codebase. But as for memory side of things there is a chance that the rule is doing something that retains a bunch of stuff in memory so we might figure it out I hope. Anyone is welcome to take a look at the rule for potential memory retention issues btw. |
|
Just had a quick glance at the rule code and it seems that most of the code is stateless (with an exception to a small string variable) which means that there are no easy fixes that we can make and most likely the memory consumptions comes directly from the Typescript tooling that the rule is using. So it's pretty much the same story as with the performance issue mentioned above. One thing we may take a look into is the calls that the rules makes to ESlint APIs like these: and And maybe if it's okay to cache such calls we can save a bit on the performance and possibly even on memory but it largely depends on how those APIs are implemented and what they are doing. If anyone if more familiar with how Also maybe it's a good idea to open similar issue at the upstream repo of |
|
cc @bradzacher or @jakebailey in case you would have any insights into these memory / performance things here and in #44 |
|
On the OOM front, if you run node with On the general time-based performance front, you can try running pprof-it (https://github.com/jakebailey/pprof-it) and then throw its output into https://www.speedscope.app/ to get a glimpse as to where the time is being spent. |
|
If I had to guess - typescript-eslint/typescript-eslint#1192 This plugin is going to be a big candidate to bloat memory because all information is calculated lazily - so computing types for properties, calls, imports, etc so you can grab the JSDoc will load more types than most setups will use normally. |
Running this plugin results in out of memory error
The text was updated successfully, but these errors were encountered: