problemMatcher is too complicated and should be modernised

[jasonwilliams]

One of the most frustrating things I've found with setting up a task is the problemMatcher. Its far too complicated for simple tasks such as setting up a background task to the point most don't bother to use it, which is a shame because it's quite powerful.

Here are some things worth considering:

Background Tasks

Sometimes I want to have a watch task, such as ESBuild watch. This is a pain to configure.

1. background should come out of the problemMatcher scope. This is because I don't care about matching the output, I just want to start background tasks and let VSCode know when something is being rebuilt. Even though this is straight forward in theory I now need to define loads of problemMatcher config, and I usually end up just setting $tsc as a base, which is wrong if its not a TypeScript Project. This has been brought up as far back as 2016 by @dbaeumer
2. background shouldn't force you to have a beginsPattern it makes no sense for watch tasks which start straight away and every subsequent change just triggers similar output (like “build successful”). (see edge case)

Edge Case:

ESBuild for example doesn't show any output when a watch task starts, this means beginsPattern is not applicable, "activeOnStart": true is set but a beginsPattern is still required. After the first successful build "watch build succeeded" is shown. I can't set "watch build succeeded" as the beginsPattern because it will never show until the first save, and I can't set it as endsPattern because VScode will think im just beginning a build when it has in fact ended.

My Proposal is this:

background can stay within problemMatcher for backwards compatibility but it should be a top level item within tasks. It's not tied to problemMatching, and sometimes you just want to mark the beginning and end of a build in watch mode.

beginsPattern should be optional if activeOnStart is set to true. That way whenever endsPattern is shown a build has finished. I believe this will allow VSCode to be more flexible when creating background tasks. This would also fix #6209 because now preLaunchTask can start once endsPattern has been triggered.

Steps to reproduce:

• Clone: https://github.com/styled-components/vscode-styled-components
• npm i
• run the build task
• try modifying the build task to show when running and finished (this is impossible because ESBuild doesn't show any output when it starts).

Docs:

• https://code.visualstudio.com/docs/editor/tasks
• https://code.visualstudio.com/docs/editor/tasks-appendix

Related:

• isWatching/background task as preLaunchTask in launch.json #6209

[jasonwilliams]

Hey @alexr00 @meganrogge just want to highlight this is still an issue in the form of modern codegen/bundler tools like ESBuild and SWC today.

For instance, the watcher configuration was built around tools like gulp which had a start and finish.
Start: File change detected.
Finish: Compilation complete. Watching for file changes.

But modern tooling doesn't echo out to lines like that anymore as the complication is so fast, its usually just "watch deteched", so trying to configure a beginsPattern and an endsPattern for something like esbuild doesn't really work