Including full error range in TSC output

[mjbvz]

From microsoft/vscode#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

[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?

[mjbvz]

Hmm, needs some thought. It would definitely be easier to parse but I have a few concerns:

• We expose the raw output of the running tsc command to users. I personally find it helpful to see the entire list of task errors in the console sometimes. Json output on its own would be much less helpful

• We would have to make sure that --formatter json is passed in to any tasks running on newer TS versions. I think this should generally be ok since our tasks generate the command line script to run, but I need to double check. It's possible there are many configured tasks in workspace that hard code running tsc directly and applying our standard problem matcher. They would not benefit from any new flags.

[weswigham]

@mjbvz The other thing I was thinking might work without changing how the output looks to humans is something like:

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

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

where \b is the actual backspace character escape code, thus hopefully hiding the extraneous information from rendered output (provided the renderer supports the control character), but still providing the info to match on. That's real hacky-feeling, though, which is why I think I'd much prefer to see a dedicated json-formatted output that can be as rich as we'd like, rather than trying to serve humans and machines with the same output.

[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

[sirbrillig]

👍 Another advantage of this flag would be that we could leverage other tools to gather information about errors in a project; for example, jq could be used to construct a cli command to show only errors in a certain directory or with a certain type, without needing any additional tooling on the part of tsc. (Possibly relevant existing work: https://www.npmjs.com/package/@aivenio/tsc-output-parser/v/1.0.1)