Can you add problemMatcher?

[chrisands]

trafficstars

What is the problem you're trying to solve?

I'd like to have problemMatcher to faster go around stylelint errors in vscode, when launching stylelint via task

What solution would you like to see?

I'm not sure if it is possible inject into extension problem matcher, but I wrote matcher that works.

Here's an example of default problem matchers.

And task with stylelint problem matcher:

{
      "type": "npm",
      "script": "lint:stylelint",
      "problemMatcher": {
        // The problem is owned by the cpp language service.
        "owner": "stylelint",
        // The file name for reported problems is relative to the opened folder.
        "fileLocation": ["relative", "${workspaceFolder}"],
        // The actual pattern to match problems in the output.
        "pattern": [
          {
            "regexp": "^([^\\s].*)$",
            // The first match group matches the file name which is relative.
            "file": 1
          },
          {
          // The regular expression. Example to match: helloWorld.c:5:3: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
          "regexp": "^\\s+(\\d+):(\\d+)\\s+(✖)\\s+(.+)$",
          // The second match group matches the line on which the problem occurred.
          "line": 1,
          // The third match group matches the column at which the problem occurred.
          "column": 2,
          // The fourth match group matches the problem's severity. Can be ignored. Then all problems are captured as errors.
          "severity": 3,
          // The fifth match group matches the message.
          "message": 4
        },
      ]
      },
      "label": "npm: lint:stylelint",
      "detail": "stylelint **/*.{css,sass,scss}"
    }

[iva2k]

This is a great start! May I suggest to turn it into a PR?

Also there are few wrinkles - with the proposed matcher, not all problems end up parsed. This below output only produces 1 problem and for 1 file only:

src/index.css
  24:1   ✖  Unexpected qualifying type selector                                       selector-no-qualifying-type
  36:1   ✖  Unexpected qualifying type selector                                       selector-no-qualifying-type
  36:1   ✖  Unexpected qualifying type selector                                       selector-no-qualifying-type
  44:1   ✖  Expected "#root" to have no more than 0 ID selectors                      selector-max-id
  48:1   ✖  Expected class selector ".row" to match pattern                           selector-class-pattern     
            "^(?:(?:o|c|u|t|s|is|has|_|js|qa)-)?[a-zA-Z0-9]+ (?: -[a - zA - Z0 - 9]
            +) * (?: __[a - zA - Z0 - 9] + (?: -[a - zA - Z0 - 9] +) *) ? (?: --[a -
            zA - Z0 - 9] + (?: -[a - zA - Z0 - 9] +) *) ? (?: \[.+\])?$"
  52:1   ✖  Expected class selector ".clip" to match pattern                          selector-class-pattern     
            "^(?:(?:o|c|u|t|s|is|has|_|js|qa)-)?[a-zA-Z0-9]+ (?: -[a - zA - Z0 - 9]
            +) * (?: __[a - zA - Z0 - 9] + (?: -[a - zA - Z0 - 9] +) *) ? (?: --[a -
            zA - Z0 - 9] + (?: -[a - zA - Z0 - 9] +) *) ? (?: \[.+\])?$"
...

[iva2k]

I was able to improve problemMatcher to grab all 2- and 3-line results, used an array of 2 problemMatchers (1st works for 3-line errors, 2nd works for 2-line errors, and don't ask me why it works - I have no idea, "loop": true in 3rd regexp block must be looping to the 2nd block, not to the 1st as one would expect):

    {
      "type": "npm",
      "script": "lint:stylelint",
      "problemMatcher": [
        {
          "owner": "stylelint",
          "fileLocation": [
            "relative",
            "${workspaceFolder}"
          ],
          "pattern": [
            {
              "regexp": "^([^\\s].*)$",
              "file": 1
            },
            {
              "regexp": "^\\s+(\\d+):(\\d+)\\s+(✖)\\s+(.+)\\s(\\S+)\\s*$",
              "line": 1,
              "column": 2,
              "severity": 3,
              "message": 4,
              "code": 5
            },
            {
              "regexp": "^(\\s\\s\\s+(\\D.*)[\\n\\r]+)+",
              "message": 1,
              "loop": true
            }
          ]
        },
        {
          "owner": "stylelint",
          "fileLocation": [
            "relative",
            "${workspaceFolder}"
          ],
          "pattern": [
            {
              "regexp": "^([^\\s].*)$",
              "file": 1
            },
            {
              "regexp": "^\\s+(\\d+):(\\d+)\\s+(✖)\\s+(.+)\\s(\\S+)\\s*$",
              "line": 1,
              "column": 2,
              "severity": 3,
              "message": 4,
              "code": 5,
              "loop": true
            }
          ]
        }
      ],
      "label": "npm: lint:stylelint",
      "detail": "stylelint **/*.{css,sass,scss}"
    }

The result in "PROBLEMS" is complete:

[adalinesimonian]

Copying some of my response from https://github.com/stylelint/vscode-stylelint/pull/221#issuecomment-975186460:

After some testing, it doesn't look like the matcher proposed above properly works when it is provided by the extension, unlike how it works when used in the project's configuration. VS Code has proper multiline message support tracked in microsoft/vscode#112686 and programmatic matcher support tracked in microsoft/vscode#59337, either of which would resolve this issue and let us correctly match Stylelint's default formatter.

In the meantime, we could implement problem matchers for Stylelint formatters that don't have multiline messages, which would work just fine with current support.

[jaens]

One solution is to use --formatter=compact on the CLI and the following matcher:

"problemMatcher": {
    "source": "stylelint",
    "owner": "stylelint",
    "fileLocation": "absolute",
    // Similar to ESLint-compact
    "pattern": {
        "regexp": "^(.+): line (\\d+), col (\\d+), (\\w+) - (.+)( \\((.+)\\))?$",
        "file": 1,
        "line": 2,
        "column": 3,
        "severity": 4,
        "message": 5,
        "code": 6,
    },
},