--extendedDiagnostics and --generateTrace do not work

[blake-newman]

The following tooling is useful for diagnosing TypeScript performance issues in applications.

Reports of slow IDE experiences may not be directly due to Volar but underlying poor preforming hot code in applications. In our case we have a very large project and have always suffered performance issues. Volar doesn't seem to respond well; likely due to it now generating more typing for vue files.

I don't want to create yet another issue about bad performance with Volar; because it may not be due to Volar itself but underlying poor performance in application code.

The ability to use this tooling will help users (and ourselves) be able to triage performance issues before blaming the tooling; however the methods to triage performance issues do not work.

I've taken a look myself into why vue-tsc is not reporting on diagnostics; but i've not yet found any resolutions as to why this may be.

Extended Diagnostics

yarn vue-tsc --extendedDiagnostics

Files:                         7102
...
Types:                           80 <--
Instantiations:                   0 <--
...

yarn tsc --extendedDiagnostics

Files:                        3203
...
Types:                      293160
Instantiations:             661562
...

As you can see with vue-tsc the extended diagnostics is reporting more files checked (which makes sense as this would be the vue files), but the types and instantiations are basically no longer being reported.

Trace Generation

yarn vue-tsc --generateTrace trace

/home/blake/work/attest-maker-fe/node_modules/typescript/lib/tsc.js:2099
            throw e;
            ^

Error: Debug Failure. False expression.

This error appears because the trace information is empty; which is not expected. Which indicates tracing and diagnostic information is bailing out.

---

Removing the generated code for VLS, which causes diagnostic errors (we use TSX and vue 2 so it isn't required to be generated in our scenario). These errors are filtered out but I was curious if that caused bail out of counting and tracing type information. After removing all diagnostic errors from generated code it still fails; so this tells me that the issue is not directly related to the generated code.

[johnsoncodehk]

Hi @blake-newman, thanks for your shares and the fair worded :). I can't reproduce this problem in https://github.com/johnsoncodehk/volar-starter but I try to fix, it do not release yet but you can try it in local env by following steps:

1. Clone this repo.
2. Run $ pnpm i && npm run build on local volar repo.
3. Run $ node [relative_path_to_volar_repo]/packages/vue-tsc/bin/vue-tsc.js --extendedDiagnostics on your project.

If it still not working please provide repro case so I can check the difference.

[blake-newman]

@johnsoncodehk thank you for the quick fix.

This has fixed --extendedDiagnostics 🙌

--generateTrace seems to reporting the same error. I'll continue to prod around when I can and try to create a reproduction for yourself. I may invite you to the org repo after gaining permission as it may be hard to know what exactly is causing the failure it could be something unique to our codebase.

We have some bank holdays over next couple of days in UK so will action inviting you to repository if I'm unable to triage and resolve myself.

[blake-newman]

So from what i can tell the issue is due to the following:

There are many outputs in typescript. When tracing the tracingEnabled.stopTracing method is called within tsc.js

The diagnostics and information is captured in tsserverlibrary.js, and the tracing logic is called via tsc.js. Which is why the information is empty.

I'm not sure what is causing the above; but that is the reason its failing.

[johnsoncodehk]

I can reproduce --generateTrace command error in volar-starter so it do not need repro case, thank you. But I'm not sure it can fix because cross tsc -- tsserverlibrary to patch ts.tracing may not be possible.

[blake-newman]

@johnsoncodehk i believe i found a way to enable this feature; not sure is the solution is appropriate but PR'd it anyway

[johnsoncodehk]

Thanks for investigating it!