Handle TypeScript Diagnostics like V8 Syntax errors in Rust

[kitsonk]

Opening this for tracking purposes, but I will be working on it. In a chat with Ry, he pointed out that TypeScript Diagnostics are very similar to the structure of V8 Syntax errors. It makes sense to further abstract the compiler from the rest of Deno, that instead of the compiler.ts logging out the Diagnostics returned when compiling a module and exiting, that the diagnostics are passed back to Rust and Rust figures out what to do (which would be log them out and exit).

This means that the compiler would return something like this:

interface CompileResponse {
  outputCode: string;
  sourceMap?: string;
  diagnostics?: Diagnostic[];
}

This would make it easier in the longer term to provide a cleaner compiler API that would allow easy implementation in the runtime of other compilers.

[ry]

Note that #1793 matches colors with JSError and TypeScript errors. This will be unnecessary to conform to if we can shoehorn TS diagnostics into the JSError format.

[kitsonk]

While they are related, a JSError and a TypeScript Diagnostic are not compatible.

The interface for JSError would be:

interface JSError {
  message: string;
  sourceLine: string;
  scriptResourceName: string;
  lineNumber: number;
  startPosition: number;
  endPosition: number;
  errorLevel: number;
  startColumn: number;
  endColumn: number;
  frames: JSFrame[];
}

interface JSFrame {
  line: number;
  column: number;
  functionName: string;
  scriptName: string;
  isEval: boolean;
  isConstructor: boolean;
  isWasm: boolean;
}

While a Diagnostic is a bit different and would look something like this:

interface Diagnostic {
  category: DiagnosticCategory;
  code: number;
  line: number;
  scriptName: string | undefined;
  startPosition: number | undefined;
  endPosition: number | undefined;
  message: string | DiagnosticMessageChain;
}

interface DiagnosticMessageChain {
  message: string;
  category: DiagnosticCategory;
  code: number;
  next?: DiagnosticMessageChain;
}

enum DiagnosticCategory {
  Warning = 0,
  Error = 1,
  Suggestion = 2,
  Message = 3
}

[ry]

So the main difference here is that JSError has Frames and Diagnostics are a list of errors.

1. Some errors from V8 do not include stack frames - like syntax errors. So we can safely ignore JSFrame.

2. It seems we could map JSError[] <--> DiagnosticMessageChain

3. There is also a "category" for JSErrors which I haven't exposed (known as ErrorLevel in V8) https://github.com/v8/v8/blob/b152bb75f880366cc0a015de30d08a84a52de904/include/v8.h#L1784-L1787

[kitsonk]

I assume that the ErrorLevel value is reflected in this enum? It sort of aligns but is still different. In particular there is the Suggestion diagnostic, which never actually manifests in a console output, as it is a class of diagnostics used with the language service to allow things like code refactoring suggestions.

Based on everything I have merged together something that I think everything can conform to:

interface DenoDiagnostic {
  /** A string message or an ordered array of further diagnostics */
  message: string | DenoDiagnostic[];

  /** The text of the source line related to the diagnostic */
  sourceLine?: string;

  /** The line number that is related to the diagnostic */
  lineNumber?: number;

  /** The name of the script resource related to the diagnostic */
  scriptResourceName?: string;

  /** The start position related to the diagnostic */
  startPosition?: number;

  /** The end position related to the diagnostic */
  endPosition?: number;

  /** The category of the diagnostic */
  category: DenoDiagnosticCategory;

  /** A number identifier */
  code?: number;

  /** The origin of the diagnostic */
  source?: DenoDiagnosticSources;

  /** The the start column of the sourceLine related to the diagnostic */
  startColumn?: number;

  /** The end column of the sourceLine related to the diagnositc */
  endColumn?: number;

  /** Any frames of a stack trace related to the diagnostic */
  frames?: DenoDiagnosticFrame[];
}

enum DenoDiagnosticCategory {
  Log = 0,
  Debug = 1,
  Info = 2,
  Error = 3,
  Warning = 4,
  Suggestion = 5
}

enum DenoDiagnosticSources {
  V8 = 0,
  Rust = 1,
  TypeScript = 2,
  Runtime = 3
}

interface DenoDiagnosticFrame {
  line: number;
  column: number;
  functionName: string;
  scriptName: string;
  isEval: boolean;
  isConstructor: boolean;
  isWasm: boolean;
}

I've added a source, which while not used at the moment could be important information, especially if we have a user land compiler APIs.

[kitsonk]

I suspect the ErrorLevel is a value based on this enum? If that is the case it sort of aligns, but is a bit different.

Based on all of this, I think this is an interface we can live with and conform everything to:

interface DenoDiagnostic {
  /** A string message or an ordered array of further diagnostics */
  message: string | DenoDiagnostic[];

  /** The text of the source line related to the diagnostic */
  sourceLine?: string;

  /** The line number that is related to the diagnostic */
  lineNumber?: number;

  /** The name of the script resource related to the diagnostic */
  scriptResourceName?: string;

  /** The start position related to the diagnostic */
  startPosition?: number;

  /** The end position related to the diagnostic */
  endPosition?: number;

  /** The category of the diagnostic */
  category: DenoDiagnosticCategory;

  /** A number identifier */
  code?: number;

  /** The origin of the diagnostic */
  source?: DenoDiagnosticSources;

  /** The the start column of the sourceLine related to the diagnostic */
  startColumn?: number;

  /** The end column of the sourceLine related to the diagnositc */
  endColumn?: number;

  /** Any frames of a stack trace related to the diagnostic */
  frames?: DenoDiagnosticFrame[];
}

enum DenoDiagnosticCategory {
  Log = 0,
  Debug = 1,
  Info = 2,
  Error = 3,
  Warning = 4,
  Suggestion = 5
}

enum DenoDiagnosticSources {
  V8 = 0,
  Rust = 1,
  TypeScript = 2,
  Runtime = 3
}

interface DenoDiagnosticFrame {
  line: number;
  column: number;
  functionName: string;
  scriptName: string;
  isEval: boolean;
  isConstructor: boolean;
  isWasm: boolean;
}

In particular it has the source of the error which will be important long term, especially if we have a user land compiler API.