2.1.8版本代码提示极慢，恢复到2.1.6版本后正常

[AKKIRR]

Vue - Official extension or vue-tsc version

^2.0.21

VSCode version

1.88.1

Vue version

^3.4.29

TypeScript version

~5.4.0

System Info

No response

package.json dependencies

{
  "name": "easyip",
  "version": "0.0.0",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite --open",
    "build": "run-p type-check \"build-only {@}\" --",
    "preview": "vite preview",
    "build-only": "vite build",
    "type-check": "vue-tsc --build --force"
  },
  "dependencies": {
    "aos": "^2.3.4",
    "axios": "^1.7.7",
    "cos-js-sdk-v5": "^1.8.4",
    "dayjs": "^1.11.13",
    "echarts": "^5.5.1",
    "element-plus": "^2.8.2",
    "pinia": "^2.2.2",
    "pinia-plugin-persistedstate": "^3.2.3",
    "qrcode.vue": "^3.4.1",
    "tdesign-vue-next": "^1.9.9",
    "uuid": "^10.0.0",
    "vue": "^3.4.29",
    "vue-i18n": "^9.14.0",
    "vue-router": "^4.3.3",
    "xlsx": "^0.18.5"
  },
  "devDependencies": {
    "@tsconfig/node20": "^20.1.4",
    "@types/aos": "^3.0.7",
    "@types/node": "^20.14.5",
    "@types/uuid": "^10.0.0",
    "@vitejs/plugin-vue": "^5.0.5",
    "@vue/tsconfig": "^0.5.1",
    "npm-run-all2": "^6.2.0",
    "sass": "^1.78.0",
    "sass-loader": "^16.0.1",
    "typescript": "~5.4.0",
    "vite": "^5.3.1",
    "vue-tsc": "^2.0.21"
  }
}

Steps to reproduce

输入代码时

What is expected?

代码快速提示

What is actually happening?

代码提示很忙

Link to minimal reproduction

No response

Any additional comments?

No response

[KazariEX]

Please provide a minimal reproduction.

[haivu2912]

I have the same issue. i have update to 2.1.8 and it make VSCode run with 100% CPU, have try to down 2.1.6 or up to newest 2.1.10 but no effect. Any help ?

[florian-g2]

Same issue here. Volar seems to be in some kind of loop which results in a high performance impact on the VSCode window process. The memory usage of volar is steadily increasing 1 MiB every 2 seconds with a constant ~4% CPU utilization on my system. The VSCode window process is at 30% usage with somewhat constant memory usage (is being actively garbage collected as it seems)

The issues does not appear immediately but some time later when developing. Are there any diagnostics I can pull from VSCode or the extension that could help?

EDIT: still occurring with 2.1.6 and vscode 1.94.2 :(

[florian-g2]

8 seconds of VSCode profiling shows it is full with thousands onmessage handling calls and directly following GC calls. So thats probably the reason for the very high CPU usage in the extension host process. The onmessage method is from the extension host rpc communication code. Yeah not much insight, so volar is communicating tons of events to the host.

[florian-g2]

Good news: It looks like the issue is rooted in a race condition in the 0.2.0 version of the vscode-goto-alias extension released last week. The VSCode process explorer fooled me here because it only shows extensions which have a running child process. The vscode-goto-alias extension is not listed in the process explorer and runs directly in the extension host. The CPU usage in Volar was just a symptom of the infinite loop running in the vscode-goto-alias extension.

The GitHub issue in the vscode-goto-alias repo for reference: https://github.com/antfu/vscode-goto-alias/issues/23

A 0.2.1 fix version was just released. It resolved it for me. Do any of you also have the vscode-goto-alias installed? Could you check if 0.2.1 also resolves it for you?

[zhangvj]

Good news: It looks like the issue is rooted in a race condition in the 0.2.0 version of the vscode-goto-alias extension released last week. The VSCode process explorer fooled me here because it only shows extensions which have a running child process. The vscode-goto-alias extension is not listed in the process explorer and runs directly in the extension host. The CPU usage in Volar was just a symptom of the infinite loop running in the vscode-goto-alias extension.

The GitHub issue in the vscode-goto-alias repo for reference: antfu/vscode-goto-alias#23

A 0.2.1 fix version was just released. It resolved it for me. Do any of you also have the vscode-goto-alias installed? Could you check if 0.2.1 also resolves it for you?

It seems that this is not the only problem. Even without this plugin installed, the CPU usage remains high after some time, so there might be another issue causing it.

[zhangvj]

Good news: It looks like the issue is rooted in a race condition in the 0.2.0 version of the vscode-goto-alias extension released last week. The VSCode process explorer fooled me here because it only shows extensions which have a running child process. The vscode-goto-alias extension is not listed in the process explorer and runs directly in the extension host. The CPU usage in Volar was just a symptom of the infinite loop running in the vscode-goto-alias extension. The GitHub issue in the vscode-goto-alias repo for reference: antfu/vscode-goto-alias#23 A 0.2.1 fix version was just released. It resolved it for me. Do any of you also have the vscode-goto-alias installed? Could you check if 0.2.1 also resolves it for you?

It seems that this is not the only problem. Even without this plugin installed, the CPU usage remains high after some time, so there might be another issue causing it.

My issue with high CPU usage was caused by this plugin. I hope this information can be helpful to you.

[pzgz]

I also have issue after 2.1.8 but really have no clues yet. After upgraded to version after 2.1.8 including 2.1.10, always failed on building, and I found out the root is because of type:check. Somehow the error traces are really meme, such as following:

❯ pnpm run type:check

> dummy_project@0.1.0 type:check /project_source_root
> vue-tsc --noEmit --skipLibCheck

/project_source_root/node_modules/.pnpm/vue-tsc@2.1.10_typescript@5.6.3/node_modules/vue-tsc/index.js:34
            throw err;
            ^

RangeError: Maximum call stack size exceeded
    at resolveEntityName (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:48208:29)
    at resolveTypeReferenceName (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:58800:20)
    at getTypeFromTypeReference (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:59005:18)
    at getTypeFromTypeNodeWorker (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:61656:16)
    at getTypeFromTypeNode (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:61618:41)
    at getTypeFromIndexedAccessTypeNode (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:61033:26)
    at getTypeFromTypeNodeWorker (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:61696:16)
    at getTypeFromTypeNode (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:61618:41)
    at getContextualType (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:71714:94)
    at pushCachedContextualType (/project_source_root/node_modules/.pnpm/typescript@5.6.3/node_modules/typescript/lib/tsc.js:71768:7)

Node.js v20.11.1
 ELIFECYCLE  Command failed with exit code 1.

I have tried to added --traceResolution --diagnostics, but still, cannot find out which file is causing the error, changed vue-tsc to 2.1.6 will fix the issue instantly.

But the tricky part is, I have another project, which has been upgraded to 2.1.8 and 2.1.10 for vue-tsc, but that is no issue at all for that project. I have made sure the tsconfig.json file are the same for two projects. But it's still very hard for me to nail the root cause without useful information provided for which file is causing issue.

The only clue is, if I change "type:check": "vue-tsc --noEmit --skipLibCheck", to "type:check": "tsc --noEmit --skipLibCheck",, there will be no error, so I guess that's issue when vue files have been checked.