Test "server ready" feature in integrated terminal

[weinand]

Test for #69898:

• macOS @auchenberg
• linux @joaomoreno
• windows @jrieken

Complexity: 3

For a description of the feature, please see #69311 (comment).

In this milestone we've added support for detecting the trigger message in the integrated terminal (in addition to the debug console supported last milestone).
And we improved the error message if the "Debugger for Chrome" is not installed if a user configures the "server ready" feature to start a browser debug session.

Verify that....

• it works out of the box for a node.js "express" application both for openExternally and debugWithChrome actions (see https://code.visualstudio.com/docs/nodejs/nodejs-tutorial#_an-express-application for how to create an express app)
• create a simple server application in another language (e.g. C# or Python, etc.) and configure the "pattern" and "uriFormat" properties to match the trigger message.
• use intellisense to configure the "server ready" feature to start a browser debug session. Verify that an error dialog is shown if the "Debugger for Chrome" is not installed.

[jrieken]

Unable to test this with express-app-sample...

[joaomoreno]

Was able to test this with a regular server:

const http = require('http');

const port = 3001;
const app = http.createServer((req, res) => {
  res.write('Hello world!');
  res.end();
});

app.listen(port);
console.log(`server listening at port ${port}`);

With the pattern:

        "pattern": "server listening at port ([0-9]+)",

Even cooler, after installing the Debugger for Chrome, I tested this one, which opens Chrome on start and breaks on that client side breakpoint.

const http = require('http');

const port = 3001;
const app = http.createServer((req, res) => {
  res.write(`<script>debugger;</script>`);
  res.end();
});

app.listen(port);
console.log(`server listening at port ${port}`);

[weinand]

The default app generated by the express generator has changed and does not spit out the Listening on port 3000 message any more.

This can be easily fixed:

• open bin/www
• add console.log('listening on port ' + bind) at the end of the onListening()function:

function onListening() {
  var addr = server.address();
  var bind = typeof addr === 'string'
    ? 'pipe ' + addr
    : 'port ' + addr.port;
  debug('Listening on ' + bind);
  console.log('listening on ' + bind);
}

[jrieken]

I understand console.log I think what blocks me is that in 9 out of 10 cases debugging just doesn't work for me. Spinning forever not signs of launching

[weinand]

I'm already looking into this issue on Windows....

[weinand]

I'm not able to reproduce node.js debugging issues on Windows.
I tried with node.js 10.2 and 10.15

[jrieken]

let debug on my machine then

[jrieken]

This seems very flaky (and silent to me). I need a couple of restarts of my VM for debugging to work reliably. Opening firefox only worked after the 5th try, it was likely installing an update, but I had no clue what's going on

[auchenberg]

Validated all steps using my https://github.com/auchenberg/nodejs-shopping-cart on MacOS with no problems.

I agree with #69311 and #71177, it would be great to have a some logging that also outputs if the pattern doesn't match anything.

[weinand]

It will be difficult to log if the pattern doesn't match anything.
The program output that gets scraped appears at any time while the program runs.
When do we know that the pattern will not match anything?

[auchenberg]

It's more in the configuration phase, where you don't know whether your regex is working or not, but you could argue that's a generel regex problem ;)