Including full error range in TSC output

From https://github.com/Microsoft/vscode/issues/70465

Repo

1. For the TS code with strict enabled:

   const obj = {
       prop: Date.now() ? 'str' : undefined
   }
   
   obj.prop.toLowerCase();
   

2. Run a tsc task in VS Code to see reported errors (make sure to close the ts file as well)

Problem We currently only report the potential undefined access error on obj in the line obj.prop.toLowerCase();. The correct range should span obj.prop.

The root cause of this is that VS Code’s problem matcher does not have the full range of the error from tsc, only the start line and column. Here’s the tsc output:

src/index.ts:7:1 - error TS2532: Object is possibly 'undefined'.

7 obj.prop.toLowerCase();
  ~~~~~~~~

With the current tsc output, there is also no way to extract the full range of the error.

Request Somewhere in the line src/index.ts:7:1 - error TS2532: Object is possibly 'undefined'. , add the end position as well so that tooling can properly highlight it. We would want to do this in a way that doesn’t detract from the error’s human readability. This needs some thought

[jamiebuilds]

Lots of times, JSON output is useful for connecting various build tools.

Right now it’s already possible to use Regex to parse out error messages:

/^(.*)\((\d+),(\d+)\): (.*) (TS\d+): (.*)$/gm
// with named capture groups
/^(?<filepath>.*)\((?<line>\d+),(?<column>\d+)\): (?<category>.*) (?<type>TS\d+): (?<message>.*)$/gm

However, this isn’t very portable, it’d be much nicer if you could specify a way to emit errors/warnings as JSON.

tsc --noEmit --json # or whatever flag

interface TSCError {
  filepath: string
  line: number
  column: number
  category: "error" | "warning"
  type: "TS0000" | "TS0001" | ...,
  message: string
}

interface TSCJSONOutput {
  errors: TSCError[]
}

Other output can be printed to stderr, but stdout should be pipe-able as valid JSON.

tsc --noEmit --json | jq .errors

[weswigham]

@mjbvz How would you feel about a --formatter json command line option for providing diagnostics in a machine readable format from the command line tools? Or is that too far and away from the current problem matcher infrastructure to be useful?