Provide Angular Build Problem Matcher

[JohnGalt1717]

I have the following task for build:

{
			"label": "build",
			"type": "npm",
			"script": "build",
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"isBackground": true,
			"problemMatcher": {
				"owner": "typescript",
				"source": "ts",
				"applyTo": "closedDocuments",
				"fileLocation": ["relative", "${workspaceRoot}/src"],
				"pattern": "$tsc",
				"background": {
					"activeOnStart": true,
					"beginsPattern": {
						"regexp": "(.*?)"
					},
					"endsPattern": {
						"regexp": "Compiled |Failed to compile."
					}
				}
			}
		},

This used to show errors/warnings under problems. With the new syntax it doesn't work and I can't find any information on how this needs to be fixed to parse errors for angular properly.

[kyliau]

I don't think this has anything to do with language service since it neither compiles the program nor change user's build config.

[JohnGalt1717]

@kyliau In most cases it's the language service that provides the pattern matching tools. Since Angular now has a non-standard error reporting from the tsc tools, I'd suggest that these are needed in the language services so that we can link up problems again.

[ayazhafiz]

Could you provide an example of your problem matcher working and how it doesn't when the language service is enabled?

[JohnGalt1717]

@ayazhafiz The above worked with Angular 8 and is part of the quickstart sample for Angular and vs code. (litterally copy and pasted) This resulted in all errors and warnings going to the problems tab and if there was a build failure it would stop debug.

It does not work in Angular 9. Problems aren't matched and fails don't stop debug.

[ayazhafiz]

I am not very familiar with VSCode build scripts or problem matching. I will look into the quickstart example you mentioned. If you are able to provide any other examples it would be appreciated.

[ayazhafiz]

Okay, a problem matching contribution can be added to the extension: https://code.visualstudio.com/api/references/contribution-points#contributes.problemMatchers. The compiler can spit out a lot of different kinds of errors (tsc, ng compiler, css, ...), so this will have to be comprehensive.

[JohnGalt1717]

The ms build problem matcher is called $msCompile. I can't find the source code but perhaps someone else would have better luck finding it?

[ayazhafiz]

The MS build problem matcher would probably not be reusable for Angular's. If you're looking for how a problem matcher contribution can be constructed, there is an example in the VS Code docs.

[kvart714]

Hello everybody,

I’ve updated Angular to 11 version and have faced with the issue.

The standard typescript problem matcher of VS Code ($tsc) cannot parse ng build errors anymore.

I have reviewed VS Code source code and have found a regular expression which parses errors from tsc (link).

The following regex is used:
/^([^\s].*)[\(:](\d+)[,:](\d+)(?:\):\s+|\s+-\s+)(error|warning|info)\s+TS(\d+)\s*:\s*(.*)$/

But Angular displays errors in the following formats now:
Error: src/app/app.component.ts:9:18 - error TS1005: ';' expected.

and problem matcher takes the row 'Error: src/app/app.component.ts' as a file path with the extra ‘Error: ’ word at the beginning.
That causes incorrect file paths building and VS Code failing during attempt to open the file with the error:

I don’t know whom to reach with this issue and this branch is the single one which I’ve found in all angular/angular-cli/vscode repositories, that’s why I’ve written it here.

Moreover, problem matcher $msCompile source code you mentioned is located next to it. But I don’t understand why you even need $msCompile.
I use the following matcher as a temporary solution in my tasks.json:

"problemMatcher": [
  {
    "base": "$tsc",
    "pattern": {
      "regexp": "^(Error: )?([^\\s].*)[\\(:](\\d+)[,:](\\d+)(?:\\):\\s+|\\s+-\\s+)(error|warning|info)\\s+TS(\\d+)\\s*:\\s*(.*)$",
      "file": 2,
      "line": 3,
      "column": 4,
      "severity": 5,
      "code": 6,
      "message": 7
    }
  }
],

But it works half the time because the error messages are displayed in different formats.

[harishrathi]

I was getting some error when using @kvart714, so used https://regex101.com/ , pasted all errors and came up with below. This exactly matches with the default $tsc matcher except the beginning Error:

                "pattern": {
                    "regexp": "^Error: ([^\\s].*)[\\(:](\\d+)[,:](\\d+)(?:\\):\\s+|\\s+-\\s+)(error|warning|info)\\s+TS(\\d+)\\s*:\\s*(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "code": 5,
                    "message": 6
                },

current-matcher: https://github.com/microsoft/vscode/blob/149a8b71c534df0554c17b05cf1a925e9139c47f/extensions/typescript-language-features/package.json#L1105

[sherpya]

still not fixed? I have same problem on vscode 1.73 using angular 14

[JohnGalt1717]

Looks like this just got even worse with V15.

[psergei]

There is no magic. Since version 9 or 10, don't remember exactly which one exactly, they started to output colored error messages to tty. It simple means that they are using ANSI colors escape sequences. That's why none of those regular expressions above will be not working. Because they do not take into account strings like this

�[1m�[31m�[0m�[91mError: �[39m�[31m�[0m�[96msrc/app/widgets/base-widget.component.ts�[0m:�[93m45�[0m:�[93m27�[0m - �[91merror�[0m�[90m TS2552: �[0mCannot find name 'itemqq'. Did you mean 'item'?�[39m�[22m

Haven't tries this in Linux yet, but here is the solution that works for me in Windows

{
    "version": "2.0.0",
    "options": {
      "env": {
        "FORCE_COLOR": "0"
      }
    },
    "tasks": [
      {
        "type": "npm",
        "script": "build:dev:watch",
        "group": {
          "kind": "build",
          "isDefault": true
        },
        "problemMatcher": [
          {
            "base": "$tsc",
            "pattern": {
              "regexp": "^Error: ([^\\s].*?):(\\d+):(\\d+).*(error|warning|info)\\s+TS(\\d+)\\s*:\\s*(.*)$",
              "file": 1,
              "line": 2,
              "column": 3,
              "severity": 4,
              "code": 5,
              "message": 6
            }
          }
        ],
        "label": "npm: build:dev:watch",
        "detail": "ng build --watch"
      }
    ]
}

Note the environment variable name - I found it in Angular CLI repo
angular-cli-main/packages/angular/cli/src/utilities/color.ts

[JohnGalt1717]

Thanks for this, however I get a "the task cannot be tracked. Please make sure that you have a problem matcher.

I believe this is because this has to be a background task which requires the background section to be filled out which includes the start regexp and end of which there is now no concrete end to.

And again, even if this works, that's great, but this should be task providers provided by the language service and it should just work and be updated by the language service automatically.

[psergei]

It just works for me, I posted exactly how I did it in my project.
It is not a background task, it is default build task. Well, actually it works all the time :)

[psergei]

Well, that's interesting. If I run the "tsc" tool standalone - it shows me the same error output as "ng build", except the "Error: " prefix. And "tsc" tool takes "pretty: false" in compilerOptions of tsconfig.json into account. So if set to false - then tsc output doesn't contain any color-escape sequences. But ng build ignores this setting.

I think that the responsibility of the Visual Studio Code to be able to parse colored output.

[JohnGalt1717]

Well, that's interesting. If I run the "tsc" tool standalone - it shows me the same error output as "ng build", except the "Error: " prefix. And "tsc" tool takes "pretty: false" in compilerOptions of tsconfig.json into account. So if set to false - then tsc output doesn't contain any color-escape sequences. But ng build ignores this setting.

I think that the responsibility of the Visual Studio Code to be able to parse colored output.

The way ALL other languages including Dart work, is that they provide their own problemMatcher that does the work to automatically parse the output of the compiler and pull errors, warnings, suggestions etc. out of it.

It can't be the job of the tool to do so, because there could be all kinds of different types it would magically have to provide AND they could change on whim.

The typescript problemMatcher that you're using by default is in fact not part of VS Code, it's part of the Typescript language service extension for this very reason.

Hence what this issue is about. It isn't about making it work with hacks. It's about getting the angular team to do what they're supposed to do when they provide a language service extension and provide a problem matcher and preferably custom tasks for build, serve, publish and test that just work automatically without having to hack it every time they change something.

[psergei]

I'm not sure you're right. Unless you can point me to a specific part of the code which implement a specific problemMatcher in angular-cli, typeScript or anywhere else.
What I see in Angular-cli - they simply take "tsc" output and prepend the "Error :" prefix with red color.

But actually I already have the answer on the above - all those problemMatchers are in VSC codebase, grabbed the code form GH.

[JohnGalt1717]

Here's why I'm right:

The problem matchers don't work properly in background mode because there is no beginning and ending expressions that you can provide because they once again changed -- and no one updated them.

The recipes supplied by vs code for angular don't work.

Given that VS code is the ##1 most used development tool for angular, this should just work. It doesn't. It's a mess as it stands right now (i.e. variations of this issue are all over stack overflow and here every time the angular team changes their output). I should be able to do what I do with dart with a new project: click the play button and it does the rest automatically.

Why can I do this? Because the Dart Language Server also provides the recipes for the tasks and the problem matchers correctly and they update them any time there is a change and the process is automatically done for you and it's always right.

Angular doesn't provide any of this and it makes developer's lives hard for no reason. We don't get to code because we're messing with VS code to get to coding. This is exactly why we have the angular CLI and don't have to manually generate our own webpack.js file anymore: Developers were sick and tired of having to orchestrate stuff just to get it to work and it constantly broke. This is no different and needs to be fixed for the same reason and the Dart team within Google agrees with me. (And Dart's primary tool is Android studio so it isn't even like VS code is the defacto standard yet they still do it.)

All I'm asking is that the Angular Language Server plugin provide the same baseline support that the dart/flutter language server plugin does with the same quality. If you fire up a dart project in vs code you'll see what you get with tasks and they're nothing like the archane mess that Angular forces on you.

[psergei]

Not really understand what you're talking about. I just made a brand new Angular 14 project without any build tasks. And I clearly see all kind of code issues in "Problem" tab of Visual Studio Code. Either I made a mistake in TS code either wrong binding in HTML template - I just see them all in Problems.
Does it mean that language server and VCS works correctly?

[JohnGalt1717]

That only means that ts is detecting them. It kicks off its own process that is separate from the tasks. Same with the Angular server.

That doesn't mean at all that the build and serve tasks were created properly nor that they will detect errors/warnings etc. correctly.

Again, fire up dart/flutter and watch what happens with no only standard editing, but build/debug. That's what the Angular Service Provider plugin should be doing. It should work identically.

And that means that the Angular Language Service needs to provide EXACTLY the same stuff that dart/flutter does to VS Code.

[kvart714]

+errors are found only in open files, so the absence of errors does not at all guarantee that the project can be built
with a properly configured matcher and build task, we see all the errors that occur during the build process

[jdaley]

For Angular 18, this partially works:

"problemMatcher": {
  "pattern": [
    {
      "regexp": "^X \\[(ERROR)\\] ((TS|NG)\\d+): (.*)$",
      "severity": 1,
      "code": 2,
      "message": 4
    },
    {
      "regexp": ""
    },
    {
      "regexp": "^\\s*(.*):(\\d+):(\\d+):$",
      "file": 1,
      "line": 2,
      "column": 3
    }
  ],
  "background": {
    "activeOnStart": true,
    "beginsPattern": {
      "regexp": "Changes detected\\. Rebuilding\\.\\.\\."
    },
    "endsPattern": {
      "regexp": "Application bundle generation (complete|failed)"
    }
  }
}

It will recognise single-line error messages as long as the file name and line number are exactly two lines below the error message, like:

X [ERROR] TS2304: Cannot find name 'blah'. [plugin angular-compiler]

    src/main.ts:6:0:
      6 │ blah
        ╵ ~~~~

But it will not recognise multi-line error messages like:

X [ERROR] NG8001: 'blah' is not a known element:
1. If 'blah' is an Angular component, then verify that it is included in the '@Component.imports' of this component.
2. To allow any element add 'NO_ERRORS_SCHEMA' to the '@Component.schemas' of this component. [plugin angular-compiler]

    src/app/app.component.html:348:0:
      348 │ <blah />
          ╵ ~~~~~~~~

You can modify the pattern to work for that second example, but I couldn't figure out a way to make it work for both.

Problems with multi-line errors are discussed in microsoft/vscode#9635. These regex-based problem matchers have limitations so there is a suggestion to support programmatic problem matching through a new API microsoft/vscode#59337. Implementing a programmatic problem matcher might be an option for the Angular Language Service to provide a solution to this in the future.