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.
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
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:
Docs:
Related:
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
watchtask, such as ESBuild watch. This is a pain to configure.backgroundshould 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$tscas a base, which is wrong if its not a TypeScript Project. This has been brought up as far back as 2016 by @dbaeumerbackgroundshouldn't force you to have abeginsPatternit 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": trueis 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.
beginsPatternshould 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 nowpreLaunchTaskcan start once endsPattern has been triggered.Steps to reproduce:
Docs:
Related: