Add support for extendedDiagnostics json output

[maschwenk]

Context: We've been working on trying to lower our memory usage for TSC by tracking it in places like Datadog. The current way we do this is a little awkward because we to have to parse it from both successful and failing output like so:

with awkward code to handle being able to stream out the output and write it to a file so a separate file can process it.

if [ -n "${CI:-}" ]; then
    if NODE_OPTIONS='--max-old-space-size=8192' tsc --noEmit --extendedDiagnostics | tee tsc.out;
    then
      pnpm -F ci-tools parse-and-measure-typescript-diagnostics --tscOutputFileToParse "$(pwd)"/tsc.out --serviceName blah
    else
      pnpm -F ci-tools parse-and-measure-typescript-diagnostics --tscOutputFileToParse "$(pwd)"/tsc.out --serviceName blah
      exit 1
    fi
  else
    NODE_OPTIONS='--max-old-space-size=8192' tsc --noEmit --extendedDiagnostics
  fi

It feels pretty jank and I figure maybe this could be a place to step forward with json output. Open to input, as I know I'm hijacking the existing --extendedDiagonstics flag, and it seems like Typescript Go seems to be intentionally emitting the diagnostics unconditionally.

Example usage:

tsgo -p tsconfig.json --extendedDiagnostics=test.json writes to test.json
tsgo -p tsconfig.json --extendedDiagnostics=tmp/test.json writes to tmp/test.json
tsgo -p tsconfig.json --extendedDiagnostics=inline writes it to stdout as text
tsgo -p tsconfig.json omitting the flag makes tsgo silent (unless there are errors)

I feel like this might be particularly useful as large repos migrate to Typescript Go and want to have an understanding of how much better execution time and memory allocations are. Spoiler: they are great!

[jakebailey]

This isn't really the same thing as the original tsc flag; I would not personally want to add this flag, at least not under this name.

Why not just parse out the current output, which is what needs to be done with old tsc as well?

[maschwenk]

Why not just parse out the current output, which is what needs to be done with old tsc as well?

For exactly that reason, the code we wrote on our side to parse it feels pretty goofy and brittle. Happy to think of other names! The context for me is that we send this information to Datadog, so it's pretty nice to not have to maintain that code that parses out of stdout because we have to scan through potentially thousands of lines of errors to find what were looking for. When we were working on reducing our tsc memory usage, we were even keeping track of these metrics for builds with failures.

[jakebailey]

Needing to send this information somewhere is making me more nervous than before. If we add devel flags here, they're temporary until we can discuss and agree on a real flag that will also be present in tsc. tsgo itself is going to go away and be replaced tsc (with extra flags), so I would be wary about adding a flag that we'll just remove later...