Feature request: machine-readable (JSONL) diagnostics output

[Alex-Bond]

Background

Type-checking integrations that run alongside a dev server - e.g., vite-plugin-checker, or a NestJS-style backend that auto-restarts once a change type-checks cleanly - need to know, after every file change, whether the project currently has type errors. There are a few ways to get that from tsc today, but they have downsides:

1. Re-run tsc --noEmit on each change. Simple to consume (process exit code), but every run is a cold check - no incremental reuse - so it's slow on a real codebase and adds latency to every save, especially on a large codebase or many changes back to back.
2. Run tsc --watch --noEmit once and parse its stdout. This is the fast path: the watcher reuses program state and only rechecks what changed. But the output is built for humans, not machines. This causes code like this. While this is faster, it's not ideal, as any changes to the response structure or copy will cause the script to break.

As a side QOL improvement, it will allow for easier logging of the errors in CI/CD - instead of trying to figure out multiline errors, it can now be easily streamed into monitoring systems.

Proposal

A single flag that switches the entire console output stream to JSONL. This is deliberately all-or-nothing: when enabled, nothing is written as free text, so a consumer can readline → JSON.parse every line without a parser mode-switch. This also composes with --watch and --noEmit, which reuse the same reporters.

Examples of proposed output:

{"type":"diagnostic","category":"error","code":2304,"file":"src/a.ts","start":{"line":3,"character":9},"end":{"line":3,"character":12},"message":"Cannot find name 'foo'.","relatedInformation":[]}
{"type":"summary","errors":1,"warnings":0}

{"type":"status","code":6032,"message":"File change detected. Starting incremental compilation..."}
{"type":"diagnostic","category":"error","code":2304,"file":"src/a.ts","start":{"line":3,"character":9},"end":{"line":3,"character":12},"message":"Cannot find name 'foo'.","relatedInformation":[]}
{"type":"summary","errors":0,"warnings":0}

Flag

Off the top of my head, there are a couple of ways to name the flag:

1. --json - while this repeats the same approach as --pretty, it can be confused with other configurations like resolveJsonModule.
2. --pretty json - convert --pretty from a simple boolean to an advanced combo of boolean and enum. The side problem is that currently, the tsconfig.json field pretty is a boolean, and at first glance, there are no union types in the JSON parser and validator.
3. --diagnosticsFormat json - the most distinct option, but can confuse when the user tries to use --pretty and json.

To my personal taste, it looks like microsoft/typescript-go#2 is the best option. I'm not a maintainer of this codebase, so I will leave it to core contributors to decide.

stdout vs stderr

It might make sense to split into 2 streams for easier logging.

Implementation

With my limited knowledge of the codebase, I can see that it is possible to implement it by creating a new flag + adding an additional formatter in diagnostics.go.

I can work on a PR for this, but I need to know the decision about the flag before I try to implement it.

[jakebailey]

See also:

• Including full error range in TSC output #30433
• SARIF output for tsc failures #55890

Not sure if this is really the right repo to ask for this feature at this point (we are moving back soon), but it was something Google also asked for in relation to 7.0 API changes.

I don't think we're going to do it for 7.0, however.

[Alex-Bond]

Not sure if this is really the right repo to ask for this feature at this point

You want me to move to the main TS repo?

After reading the 2 issues, I think it might be even better to consider creating some form of "adapters," so it's possible to produce different outputs based on what people need. But this will cause more major changes unless we keep the current flags in place until 8.0 or later.

[jakebailey]

Not sure; if anything we'll probably just move this. I doubt we are going to stick this into 7.0 in any case.

I don't see "adapters" working, we are not going to maintain many outputs, and likely not make this pluggable through anything other than the API, which of course can already do whatever it wants

[Alex-Bond]

While it can be designed as a minor change w/o breaking anything current, I agree that it's a good idea to push it to at least 7.1 to avoid additional features that need to be cleaned up and tested before the release of 7.0.

I think I went straight into overengineering here - I was thinking about SARIF, JSONL, and potential string template outputs. In my head, the motivation for "adapters" was to make it easier for anyone who thinks they need some crazy format to create an adapter and push a PR.