Include results from `--extendedDiagnostics` when using the compiler API

[MariaSolOs]

🔍 Search Terms

extendedDiagnostics, compiler API

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

For users of the TypeScript compiler API, it would be extremely useful to include the performance statistics obtained when using the --extendedDiagnostics compiler option.

From the review I've done in this codebase, it seems like this performance information is only reported when invoking tsc directly.

📃 Motivating Example

"The compiler API can now report performance information when enabling the extendedDiagnostics compiler option"

💻 Use Cases

1. What do you want to use this for? Investigating performance variations in a project that interacts with TypeScript using the compiler API.

[jakebailey]

The main gotcha is that the perf data is global (via the native performance built-in), not scoped, so doesn't lend itself to use via the APIs at all.

[MariaSolOs]

The main gotcha is that the perf data is global (via the native performance built-in), not scoped, so doesn't lend itself to use via the APIs at all.

@jakebailey could you please elaborate on this?

A workaround I was thinking of was constructing my own report using the program from const program = createIncrementalProgram() and then get the stats I need like executeCommandLine.ts does here, but are you saying that this wouldn't work because there's global state that I wouldn't have access to?

[jakebailey]

See:

• TypeScript/src/compiler/performance.ts

  Line 103 in 3f416e0

  performanceImpl?.measure(measureName, startMarkName, endMarkName);

• TypeScript/src/compiler/executeCommandLine.ts

  Line 1190 in 3f416e0

  performance.forEachMeasure((name, duration) => {

This all is global state, backed by globalThis.performance. All of the data for extendedDiagnostics (and even --trace) is global. Having this be in the public API would be a challenge because this performance marking / tracing was never meant to be enabled outside of tsc.js, where we are only ever doing one compilation. In fact, the code that produced the extendedDiagnostics output wasn't even present in typescript.js until #58057 when I moved it there.

[jakebailey]

That being said, if you read the code in the second link, there is information from Program that you could use, that isn't global, and that could be done today. There are projects out there (like attest) which do this.