The "$tsc-webpack-watch" from "amodio.tsl-problem-matcher" problem matcher does match, but doesn't mark the task as failed

[segevfiner]

Does this issue occur when all extensions are disabled?: No

• VS Code Version: 1.67.1
• OS Version: macOS 12.3.1

Steps to Reproduce:

1. Generate a new extension using yo code, that uses webpack, and open it in VS Code.
2. Install the recommended extensions.
3. Introduce an error into extesnion.ts and close it.
4. Run the npm watch task.
5. Split the terminal that runs the task.
6. Notice that the task is marked as successful rather than failed (Checkmark instead of circled red cross).

The problem matcher from does seem to be defined correctly by testing its regex manually and the fact that it does match the start and end of webpack compilation and shows the error in the problems panel.

(P.S. Is there any tool in VS Code to make it easier to debug problem matchers?)

[meganrogge]

I believe this is fixed in the Insider's build via #149976 . Can you pls try to repro the issue there?

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[meganrogge]

repro reported by @joyceerhl

[meganrogge]

the problem count is correct because it's driven by other ts matchers

and it completes w a checkmark bc there are no lines matching that error regexp as shown above

[meganrogge]

I see the tryBegin succeeding, but then it ends prematurely because one of the ts problemMatchers exits from tryFinish before a match has been found

with this in the buffer

[meganrogge]

so the issue here is Compilation starting.... happens -> tryBegin moves on to tryFinish where it finds Compilation finished and goes back to looking for the next start pattern match, glossing over the error

[meganrogge]

@alexr00 it looks like this problem is caused by having multiple problem marchers. Have you seen this in the past?

Joyce said this started happening recently, which surprises me based on what I'm seeing here

[meganrogge]

Maybe related to #157096 which I also don't think is new

[alexr00]

@meganrogge if there haven't been any changes in problem matching then maybe the problem matcher itself changed? I agree that this looks like something that hasn't worked in a long time, if ever.

[meganrogge]

I believe there's an issue with fork-ts-check-webpack-plugin and the others.

The extension relies upon errors and warnings being reported via that plugin as described here and that's not happening clearly. It has been updated recently as well - I wonder if those updates are important and haven't been brought into the extension?

[meganrogge]

In that plugin's vscode usage example, it uses a different version of problem matchers https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/main/examples/vscode-tasks/.vscode/tasks.json#L8

[meganrogge]

I will look into this again in the next debt week

[alexdima]

I have found the following worked for me as a workaround:

            "problemMatcher": {
                "base": "$ts-webpack-watch",
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": {
                        "regexp": "."
                    },
                    "endsPattern": {
                        "regexp": "webpack [\\d.]+ compiled"
                    }
                },
            },