Currently when queried for semantic diagnostics, the language service only returns diagnostics from typechecking the program TCB. However parse errors are likely to be just as (if not more) frequent than type errors, so we should return those as well.

When getSemanticDiagnostics is called, we retrieve a compiler for the program that file is in. The file is checked for changed contents; if contents have been changed and it's an external template, we update known components using the template to have the new template:

ttc.overrideComponentTemplate parses the template and returns errors, so our work is nearly done. The only thing left to do is marshall the each of the compiler's ParseError into a ts.Diagnostic. The compiler also provides a method for creating ts.Diagnostics for a template:

A usage of which for ParseErrors is already present for the collection of components during the regular compilation pipeline:

Most of the "hard" work is already done, the only missing piece is the mapping: TemplateSourceMapping parameter expected by makeTemplateDiagnostic. Actually we have this information too, we just need TemplateTypeChecker#overrideComponentTemplate to return it to us:

fileRecord.sourceManager has information about the TemplateSourceMapping for the particular template, so we can get it from there. In particular note that overrideComponentTemplate, when called by the language service (AFAIK also the only user) should only call this for external templates (we may need to make this contract more strict/explicit), so there shouldn't need to be any extra work to be done here.

This is a "good first issue"; I have tagged it as such, if no one wants to claim it I will take a stab when I have some free time.

Side notes:

• There may be a question of who should report these errors. TemplateTypeChecker also exposes getDiagnosticsForFile, should that be extended to include parse errors? Maybe, because then the TTC can cache this stuff and be the "source of truth" for a template, but I argue no, because it should be concerned with TypeChecker and That's It ™️
• The language service's getOrCreateWithChangedFile now does more than just create a compiler; it also returns parse errors. Here is where I think it may make sense to make the contract between what language service queries should be used to identify changes in the workspace, and which can called without changed, more strict. In particular, I suggest one of the following:
  • Expose a didChange API that notifies the LS of workspace changes and returns semantic diagnostics. This fits more cleanly into how the LSP actually works (getSemanticDiagnostics is not exposed by the LSP, a server publishes a message containing diagnostics to the client). The problem with this is ts.LanguageService does not have such a method, making this idea incompatible if we need to keep the Angular LS as a tsserver plugin (but even in that case it might work if we just assume getSemanticDiagnostic calls on tsserver == changed workspace)
  • Make a strict contract that when a workspace is changed, getSemanticDiagnostics is always called and answered before any other LS API is called.
  • Propagate parse errors to the type checking phase (a sort-of "advanced" case that requires a lot of additional work, could get confusing quickly, and is probably not worth it for now)

Kind-of related to #38061