Open skolmer opened 8 years ago
@skolmer it is possible to have a watcher task as a preLaunchTask
in launch.json
. Just checkout the VScode typescript extension template - it has a watching preLaunchTask.
What is your watch task, can you create a small reproducable sample for which we can try to reproduce this.
@dbaeumer I guess it might happen that I am not getting an 'inactive' event from the tasks framework for @skolmer use case
@isidorn This is the project boilerplate I'm working on. It has a watching task that runs webpack-dev-server. If you set development
task as a prelauchTask in launch.json and hit F5 you can reproduce the described behavior.
@dbaeumer I double checked and I am not getting the Inactive event from the tasks framework in this case. Forwarding to you
@skolmer I see your point. AS a workaround couldn't you define a problemMatcher with a regexp not matching anything. In the problem matcher you then set the watching property to define regular expression that signals when the watching tasks begins and when it ends. An example of such a property for the tsc watching compilation mode is:
"watching": {
"activeOnStart": true,
"beginsPattern": "^\\s*(?:message TS6032:|\\d{1,2}:\\d{1,2}:\\d{1,2} (?:AM|PM) -) File change detected\\. Starting incremental compilation\\.\\.\\.",
"endsPattern": "^\\s*(?:message TS6042:|\\d{1,2}:\\d{1,2}:\\d{1,2} (?:AM|PM) -) Compilation complete\\. Watching for file changes\\."
}
We should support defining watch begin / end pattern without a problem pattern as well.
@dbaeumer Thanks! I wasn't aware of the watching config. This did exactly what I wanted to achieve.
{
"owner": "custom",
"pattern": [],
"watching": {
"activeOnStart": true,
"beginsPattern": "webpack: bundle is now INVALID",
"endsPattern": "webpack: bundle is now VALID"
}
}
It is showing The problem pattern is invalid. It must have at least a file, message and line or location match group.
in the output but is working as expected.
@skolmer Great to see you got it working. I will keep this issue open to address the comment https://github.com/Microsoft/vscode/issues/6209#issuecomment-218154446
@dbaeumer I couldn't find any documentation about the watching config. Would be nice to have this feature in the docs https://code.visualstudio.com/Docs/editor/tasks#_defining-a-problem-matcher
@dbaeumer My workaround (https://github.com/Microsoft/vscode/issues/6209#issuecomment-218175415) stopped working in one of the latest insider builds. The prelaunch task is now failing. Do you have a suggestion how to fix this?
@skolmer how does the task fail?
@dbaeumer This is the error message:
Error: Invalid problemMatcher description. A matcher must at least define a pattern, owner and a file location. The problematic matcher is:
{
"owner": "custom",
"watching": {
"activeOnStart": true,
"beginsPattern": "^webpack: Compiling\\.\\.\\.$",
"endsPattern": "^webpack: Compiled successfully\\.$"
}
}
@skolmer Thanks.
@skolmer I looked into the real fix for this and it basically requires some major restructuring I only want to do for the new terminal runner. Basically we need to allow to defined watching patterns on the task level as well.
I found a way how you can make this work right now with a different work around. Define the problem matcher as follows:
"problemMatcher": {
"owner": "custom",
"pattern": { "regexp": "__________" },
"watching": {
"activeOnStart": true,
"beginsPattern": "^webpack: Compiling\\.\\.\\.$",
"endsPattern": "^webpack: Compiled successfully\\.$"
}
}
As the regexp use a regular expression that doesn't match anything in the output.
As mention the real fix is to allow something like
{
"taskName": "abc",
"background": {
"activeOnStart": true,
"beginsPattern": "^webpack: Compiling\\.\\.\\.$",
"endsPattern": "^webpack: Compiled successfully\\.$"
}
}
Thanks for the workaround!
Moving to Mai due to shifted priorities.
Another important part of this enhancement is to terminate the preLaunch watch task when the debugging session is ended.
@AshleyGrant nice idea. Can you please open a separate issue since this should be done via the debugger. @isidorn FYI.
@dbaeumer done. Another thought I've had regarding this issue is that a check should be done to see if the watching task is already running. In that situation, a duplicate task probably should not be launched.
Did not make it for May due to other priorities.
Any recent updates on this? I'm also hitting this using a webpack hot-reload server to debug an electron app. :D
Any updates on this?
You can now run tasks as background tasks: https://code.visualstudio.com/docs/editor/tasks#_background-watching-tasks
This still doesn't really fully cover what the feature request is. Currently, I have to launch the background task and then launch a debugging session.
I was able to configure VS Code to launch both with the following config:
tasks.json
{
"version": "2.0.0",
"tasks": [
{
"type": "gulp",
"label": "build",
"task": "webpack-watch-dev", // gulp webpack-watch-dev is the gulp task I want to run in the background
"isBackground": true,
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
launch.json
{
// Use IntelliSense to learn about possible Node.js debug attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceRoot}/server/index.js",
"env": {
"NODE_ENV": "development"
},
"preLaunchTask": "build",
"console": "integratedTerminal"
}
]
}
Pressing F5 then starts both my gulp
task and the Node server. Annoyingly, I do have to select "Debug Anyway" from this prompt, but works fine otherwise.
Well, I stand corrected.. Maybe someone from the VS Code team can look at removing that prompt, or giving a configuration to make it go away.
Yeah, I've been meaning to confirm it's an actual bug (and not just something caused by code, as my build task does take a bit to fully start), and file an issue if so.
Running background preLaunch tasks is supported right now. The thing that is still cumbersome is to let the matcher know when a background task is active and when inactive. This can currently only be done by creating an artificial problem matcher. The issue here is about easing this and have the regexp be on the task instead of the problem matcher. But the need for these regexp will not go away. Otherwise debug can never know when a background tasks started and when it finishes its activity.
See https://github.com/Microsoft/vscode/issues/6209#issuecomment-289411630
@dbaeumer can you explain why your comment works?
More specifically what these parts do and what they are working around?
// ...
"owner": "custom",
"pattern": { "regexp": "__________" },
// ...
Currently you can't define a problem matcher without a pattern. So the pattern I picked is likely not matching anything. Otherwise it would report errors although there aren't any.
//// EDIT: I have discovered that this appears to be induced by the presence of "dependsOn". I don't know if this is a separate issue. I will try adding problem matchers to the dependent tasks but that is not my desired solution. ////
I cannot get this to work. Am I misunderstanding the intent of the current design?
I am trying to run debugging with chrome from launch.json, running webpack-dev-server, with chrome only launching after the server is running.
Instead, the launch task (Chrome) always executes immediately (before the server is initialized) if the task has isBackground set to true.
I thought I should be able to accomplish this by adding the dummy regex to the problem matcher on webpack-dev-server, and adding the begin/end regex to the background property on the problem matcher. However, the regexes in the problem matcher do not appear to affect anything (aside from that the task cannot be terminated if the main regex is omitted). ActiveOnStart also has no affect.
Chrome is run from a compound configuration in launch.json:
{
"version": "0.2.0",
"configurations": [
{
// ...
},
{
"name": "Launch_Chrome",
"type": "chrome",
"request": "launch",
"url": "http://localhost:8080",
"preLaunchTask": "webpack_dev_server_task",
}
],
"compounds": [
{
"name": "Compound",
"configurations": [
// ...
"Launch_Chrome"
]
}
]
}
and webpack-dev-server is run from tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "webpack_dev_server_task",
"command": "webpack-dev-server",
"dependsOn": [
"build_webpack_task"
],
"type": "shell",
"isBackground": true,
"problemMatcher": {
"owner": "custom",
"pattern": {
"regexp": "_____"
},
"background": {
"activeOnStart": true,
"beginsPattern": "^.*Project is running at.*$",
"endsPattern": "^.*webpack: Compiled successfully..*$"
},
}
}
]
}
@dbaeumer none of solutions mentioned above work for me (I am using 1.23.1). I have tried
"isBackground": true
, "problemMatcher" regexp ...
Still, I can see after my preLaunchTask (to start the webpack server) finished, launch.json did not launch chrome. Only after I killed preLaunchTask did it launch chrome.
Does the webpack output contain the lines Project is running at
and webpack: Compiled successfully
@dbaeumer Hello Dirk, has there been any progress on this matter? I'm having a hard time setting up a rather basic configuration with a launch configuration which runs and debugs a .netcore app, as prelaunch I need to call two tasks: one npm task to do build stuff and a second watching task for webpack devserver.
For the watching task I want to use the tsc-watch problem solver to get hints to my code when it does not compile. Is this supposed to get easier at some point in the future?
No progress yet. For the watching task: does it only compile or do you want to wait until the wepkack server is running?
Did something change in the latest update? In a previous project, I was able to get my angular front end task to run and then debug the back end using the following tasks.json code:
"command": "ng serve",
"isBackground": true,
"problemMatcher": [
"$tsc-watch",
{
"owner": "typescript",
"pattern": {
"regexp": "^([^\\s].*)\\((\\d+|\\,\\d+|\\d+,\\d+,\\d+,\\d+)\\):\\s+(error|warning|info)\\s+(TS\\d+)\\s*:\\s*(.*)$",
"file": 1,
"location": 2,
"severity": 3,
"code": 4,
"message": 5
},
"background": {
"activeOnStart": true,
"beginsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - File change detected\\. Starting incremental compilation\\.\\.\\.",
"endsPattern": "^webpack: Compiled successfully."
}
}
]
I haven't used that in a month or so because I'm on a new project. I tried to do the same thing as before, but it doesn't work.
My new code is:
{
"label": "ModelAgentFrontEnd",
"identifier": "ModelAgentFrontEnd",
"type": "shell",
"command": "ng serve",
"options": {
"cwd": "../ModelAgentFrontEnd"
},
"presentation": {
"reveal": "always",
"panel": "new"
},
"isBackground": true,
"problemMatcher": [
"$tsc-watch",
{
"owner": "typescript",
"pattern": {
"regexp": "^([^\\s].*)\\((\\d+|\\,\\d+|\\d+,\\d+,\\d+,\\d+)\\):\\s+(error|warning|info)\\s+(TS\\d+)\\s*:\\s*(.*)$",
"file": 1,
"location": 2,
"severity": 3,
"code": 4,
"message": 5
},
"background": {
"activeOnStart": true,
"beginsPattern": "^Your global Angular CLI version.*",
"endsPattern": "^webpack: Compiled successfully.*"
}
}
]
}
Any ideas as to why this doesn't work anymore? Did this stop working for anyone else?
Actually no. How does the output of the task look like?
It is a typical ng serve output. I didn't get fancy with regex at all, to make sure it works. The output is below:
Your global Angular CLI version (1.6.5) is greater than your local
version (1.6.0). The local Angular CLI version is used.
To disable this warning use "ng set --global warnings.versionMismatch=false".
@angular/compiler-cli@5.1.0 requires typescript@'>=2.4.2 <2.5.0' but 2.6.2 was found instead.
Using this version can result in undefined behaviour and difficult to debug problems.
Please run the following command to install a compatible version of TypeScript.
npm install typescript@'>=2.4.2 <2.5.0'
To disable this warning run "ng set warnings.typescriptMismatch=false".
** NG Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **
Date: 2018-06-14T18:31:45.847Z
Hash: 1b793a4a1ae8dc08feec
Time: 11918ms
chunk {inline} inline.bundle.js (inline) 5.79 kB [entry] [rendered]
chunk {main} main.bundle.js (main) 657 kB [initial] [rendered]
chunk {polyfills} polyfills.bundle.js (polyfills) 607 kB [initial] [rendered]
chunk {styles} styles.bundle.js (styles) 363 kB [initial] [rendered]
chunk {vendor} vendor.bundle.js (vendor) 11.7 MB [initial] [rendered]
webpack: Compiled successfully.
For this output activeOnStart
needs to be false this the begin pattern is present even on the first run.
I have the same problem with a Node.js app running inside a container locally. I have a bash script setting up the container and I can't attach the debugger using preLaunchTask
.
I am using:
,
"problemMatcher": {
"pattern": [{
"regexp": "!!!DO NOT MATCH ME!!!",
"file": 1,
"location": 2,
"message": 3
}],
"background": {
"activeOnStart": true,
"beginsPattern": "^.+Debugger listening.+",
"endsPattern": "-----"
}
}
And my output is
[nodemon] 1.18.1
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node --expose-gc --inspect=0.0.0.0 server.js || exit 1`
Debugger listening on ws://0.0.0.0:9229/ad551785-a8ff-47af-8e98-3e5890889205
For help, see: https://nodejs.org/en/docs/inspector
{
"level": "info",
"message": "server up @ http://localhost:5000"
}
When I change beginsPattern
to something that doesn't match anything I get the Dialog with "Debug Anyway" when I do match something it just hangs.
If I run the task and then attach manually it works.
@kilianc your ends pattern needs to match as well. This tells the debugger that the task actually has finished.
@dbaeumer in my case is a server running, so end of the process is the end of the task. I don't log anything on exit but I only ^+C
.
I am confused on how the end of the task is going to affect the debugger attaching itself. Does the debugger wait for the task to be complete?
@dbaeumer !!!!
"beginsPattern": "^Debugger listening.+$",
"endsPattern": "^For help.+$"
IT WORKS!
@dbaeumer seems like this hasn't moved in a while.
Is this feature still desired (I see it in the backlog) or should it be ditched entirely?
If this is something we'd like to have, is there a way we could break down the necessary steps to get it done?
@synthkaf this is still on the list. That is why it is On Deck
. The reason why it didn't get more tracking so far is that there is a reasonable workaround (a stupid problem pattern).
But we just discussed this last week to decide what it means to make the pattern optional. Internally not a big issue but it has impact on the API as well.
I'm able to use the workaround @skolmer outlines, but with a slight modification. You do not need to provide a pattern if you set base
, as the following does:
{
"label": "Start for Debugger",
"type": "npm",
"script": "start",
"problemMatcher": [
{
"base": "$tsc-watch", // <-- extends the TypeScript watcher
"background": {
"activeOnStart": true,
"beginsPattern": "Angular Live Development Server is listening",
"endsPattern": "「wdm」: Compiled successfully"
}
}
],
"isBackground": true,
"group": "build"
}
You still have to manually stop ng serve
after disconnecting the debugger unless you add a postDebugTask
to run a shell command to stop ng serve
.
This just broke for me. I haven't changed anything, but now the task is never signaled as complete:
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Chrome Docs Debug",
"type": "chrome",
"request": "launch",
"preLaunchTask": "npm: start:docs",
"url": "http://localhost:8080/",
"webRoot": "${workspaceFolder}/test",
"sourceMapPathOverrides": {
"webpack:///./*":"${workspaceRoot}/*",
}
},
]
}
tasks.json
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "start:docs",
"isBackground": true,
"problemMatcher": [{
"owner": "webpack",
"source": "webpack",
"fileLocation": "absolute",
"severity": "error",
"pattern": [{
"regexp": "^ERROR in (.*)$",
}, {
"regexp": "^.*$"
}, {
"regexp": "^([^:]*): ([^:]*): ([^\\(]*) \\((\\d+):(\\d+)\\)$",
"file": 2,
"message": 3,
"line": 4,
"column": 5
}],
"background": {
"activeOnStart": true,
"beginsPattern": "^.*: Hash: *$",
"endsPattern": "^.*(Compiled successfully)|(Failed to compile).*$"
}
}]
}
]
}
Chrome Debugger doesn't trigger anymore because it thinks the task isn't complete. When I kill the task (with the trash icon), then I get the usual popup to continue debugging.
Just realized, it's quite possibly from https://github.com/Microsoft/vscode/issues/65472
with watchers everywhere, i think a proper solution would be appropriate...
Status on this? I want to set up a launch task to start azurite first and then start the azure functions host before launching the powershell debug, and I can't because of this issue if I make the functions host task dependson azurite.
I'm going to look into the biu program to "consolidate" it to one task maybe as a workaround.
EDIT: Since azurite doesn't have to be "refreshed" each run, I worked around this problem by adding this to its tasks.json entry to make it always start when I first run vscode:
"runOptions": {
"runOn": "folderOpen"
},
It would be nice to have a watcher task as preLaunchTask in launch.json. At the moment this is not possible because the launch task will not start before the preLaunchTask ends. A long running preLaunchTask should have a regex similar to problemMatcher to wait for a specific text in the output window before executing the launch task. In my scenario I'm running webpack dev server as a watcher task. I want this task to run if F5 is hit and the preLaunchTask is not running. To delay the debugger launch it would be useful to test for a specific string in the output window
webpack: bundle is now VALID.