英文:
Nrwl NX JavaScript heap out of memory on lint
问题
I am working within an Nx monorepo with many Angular 15 applications, and some shared libraries. I generated a new Angular application using the nx cli, which worked great. I can serve and build the application without issue.
The issue comes when I add the tsconfig files for the new application to my eslintrc.json file
"overrides": [
{
"parserOptions": {
"project": [
"apps/new-app/tsconfig.*?.json",
"libs/shared/tsconfig.*?.json",
// ----- 15 others -----
]
}
}
]
If I add my new application to the parserOptions, then run
nx affected --target=lint
I get this error for the shared library which has not been touched
<--- Last few GCs --->
[18664:0000015D230EE780] 71334 ms: Scavenge 4044.3 (4127.2) -> 4039.4 (4128.5) MB, 12.6 / 0.0 ms (average mu = 0.835, current mu = 0.632) allocation failure
[18664:0000015D230EE780] 71386 ms: Scavenge 4047.0 (4130.1) -> 4043.9 (4131.8) MB, 14.5 / 0.1 ms (average mu = 0.835, current mu = 0.632) allocation failure
[18664:0000015D230EE780] 72392 ms: Scavenge 4048.8 (4131.8) -> 4045.8 (4150.1) MB, 989.7 / 0.0 ms (average mu = 0.835, current mu = 0.632) allocation failure
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF7DB8A0B5F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+124015
2: 00007FF7DB82C916 v8::internal::wasm::WasmCode::safepoint_table_offset+64182
3: 00007FF7DB82D992 v8::internal::wasm::WasmCode::safepoint_table_offset+68402
4: 00007FF7DC161D94 v8::Isolate::ReportExternalAllocationLimitReached+116
5: 00007FF7DC14C35D v8::SharedArrayBuffer::Externalize+781
6: 00007FF7DBFEF93C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
7: 00007FF7DBFECA54 v8::internal::Heap::CollectGarbage+4244
8: 00007FF7DBFEA3D0 v8::internal::Heap::AllocateExternalBackingStore+2000
9: 00007FF7DC00EF56 v8::internal::Factory::NewFillerObject+214
10: 00007FF7DBD416F5 v8::internal::DateCache::Weekday+1797
11: 00007FF7DC1EFA71 v8::internal::SetupIsolateDelegate::SetupHeap+494417
12: 0000015D254F5AEA
If I remove the new app from the parserOptions and run lint, everything the linter succeeds everywhere except the new application, for which the error tells me to add the tsconfig to the parserOptions
I am running on windows using node version v16.18.1 and I have tried increasing the memory available using --max-old-space-size=6144/--max_old_space_size=6144 in several ways.
Does anyone know what is causing this issue, or how to fix it? While everything works except the nx lint, my company uses nx built in lint command to verify code before it can be pushed or merged.
<details>
<summary>英文:</summary>
I am working within an Nx monorepo with many Angular 15 applications, and some shared libraries. I generated a new Angular application using the nx cli, which worked great. I can serve and build the application without issue.
The issue comes when I add the tsconfig files for the new application to my eslintrc.json file
"overrides": [
"parserOptions": {
"project": [
"apps/new-app/tsconfig.*?.json"
"libs/shared/tsconfig.*?.json"
*/ -----
15 others
-----/*
]
}
]
If I add my new application to the parserOptions, then run
> nx affected --target=lint
I get this error for the shared library which has not been touched
<--- Last few GCs --->
[18664:0000015D230EE780] 71334 ms: Scavenge 4044.3 (4127.2) -> 4039.4 (4128.5) MB, 12.6 / 0.0 ms (average mu = 0.835, current mu = 0.632) allocation failure
[18664:0000015D230EE780] 71386 ms: Scavenge 4047.0 (4130.1) -> 4043.9 (4131.8) MB, 14.5 / 0.1 ms (average mu = 0.835, current mu = 0.632) allocation failure
[18664:0000015D230EE780] 72392 ms: Scavenge 4048.8 (4131.8) -> 4045.8 (4150.1) MB, 989.7 / 0.0 ms (average mu = 0.835, current mu = 0.632) allocation failure
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF7DB8A0B5F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+124015
2: 00007FF7DB82C916 v8::internal::wasm::WasmCode::safepoint_table_offset+64182
3: 00007FF7DB82D992 v8::internal::wasm::WasmCode::safepoint_table_offset+68402
4: 00007FF7DC161D94 v8::Isolate::ReportExternalAllocationLimitReached+116
5: 00007FF7DC14C35D v8::SharedArrayBuffer::Externalize+781
6: 00007FF7DBFEF93C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
7: 00007FF7DBFECA54 v8::internal::Heap::CollectGarbage+4244
8: 00007FF7DBFEA3D0 v8::internal::Heap::AllocateExternalBackingStore+2000
9: 00007FF7DC00EF56 v8::internal::Factory::NewFillerObject+214
10: 00007FF7DBD416F5 v8::internal::DateCache::Weekday+1797
11: 00007FF7DC1EFA71 v8::internal::SetupIsolateDelegate::SetupHeap+494417
12: 0000015D254F5AEA
If I remove the new app from the parserOptions and run lint, everything the linter succeeds everywhere except the new application, for which the error tells me to add the tsconfig to the parserOptions
I am running on windows using node version v16.18.1 and I have tried increasing the memory available using --max-old-space-size=6144/--max_old_space_size=6144 in several ways.
Does anyone know what is causing this issue, or how to fix it? While everything works except the nx lint, my company uses nx built in lint command to verify code before it can be pushed or merged
</details>
# 答案1
**得分**: 1
更改我在每个应用程序的tsconfig.json中指定的方式对我来说解决了问题。最初，我有：
```json
"project": ["tsconfig.base.json"]
将其更改为：
"project": ["apps/{{app-name}}/tsconfig.*?.json"]
似乎解决了包括所有正确的文件并且没有内存问题的问题。
这是一个相当奇怪的问题，我很想听听解释。对我来说，当我迁移到 Nx 16 和 Angular 16 时，这个问题突然出现，即使在运行迁移之后也是如此。不确定你的情况是否不同。有趣的是，在CI机器上（Ubuntu 22.04.2, x64）没有任何问题，但是我的开发机器和另一台机器（都是macOS 13.4, arm64）都有这个问题。
英文:
For me, the fix was to change how I was specifying the tsconfig.json in each of my apps. Originally, I had
"project": ["tsconfig.base.json"]
Changing this to
"project": ["apps/{{app-name}}/tsconfig.*?.json"]
seemed to fix the issue with all of the correct files included and no memory issues.
Pretty weird issue, I'd be interested to hear an explanation. For me, it popped up randomly when I migrated to Nx 16 and Angular 16—even after running the migrations. Not sure if yours was a different scenario. Interestingly enough, there were no issues linting on a CI machine (Ubuntu 22.04.2, x64), but both my dev machine and another machine (both macOS 13.4, arm64) had the problem.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论