doc: match debugger output & instructions to master behavior

[hybrist]

Follow-up to #13777. Updates debugger.md with instructions & output that match behavior in node 8 / master.

Previously the instructions would at best trigger deprecation warnings and at worst fail completely.

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

[vsemozhetbyt]

I do not see this line in 8.1.2 output.

[vsemozhetbyt]

If you have not changed the code example below, this should still remain:

  3   debugger;

[hybrist]

Yeah, I wasn't sure about the exact "order" here. Because it first shows this and then later/below says (emphasis mine):

Inserting the statement debugger; into the source code of a script will
enable a breakpoint at that position in the code:

I interpreted that as "this is showing the original script run, then you insert debugger, then you run it again".

[vsemozhetbyt]

I do not see this line in 8.1.2 output.

[hybrist]

Weird, I'm seeing it on master/this branch:

I also see it on 8.1.2:

I'm taking a TODO to check where the message is generated and why it wouldn't happen consistently. Might be a timing and/or platform issue..?

[vsemozhetbyt]

I see this order in 8.1.2:

debug> next
< world
break in myscript.js:5

[hybrist]

Yep! Missed that one.

[vsemozhetbyt]

It seems this also should be:

$ node inspect myscript.js

[hybrist]

Good catch!

[vsemozhetbyt]

I do not see this line in 8.1.2 output.

[vsemozhetbyt]

2 -> 22 (due to copyright added recently):

debug> setBreakpoint('mod.js', 22)

[hybrist]

Interesting. I think the current instruction happened to work because it was smart enough to "shift" beyond the comment. But using 22 is definitely less confusing. 👍

[vsemozhetbyt]

2 -> 22:

break in test/fixtures/break-in-module/mod.js:22

[vsemozhetbyt]

Maybe we also should update the link to redirected one (line 194):
https://chromedevtools.github.io/debugger-protocol-viewer/
->
https://chromedevtools.github.io/devtools-protocol/

[vsemozhetbyt]

the last example may also be updated to:

$ node --inspect index.js
Debugger listening on ws://127.0.0.1:9229/dc9010dd-f8b8-4ac5-a510-c1a114ec7d29
For help see https://nodejs.org/en/docs/inspector

[benjamingr]

I'm LGTM if the nits raised by @vsemozhetbyt are attached - I see the same output as @vsemozhetbyt - without the "Debugger attached." line.

[hybrist]

I'm not sure what's up with the "Debugger attached". I'm testing on macOS 10.12.5 if that makes any difference..? Anyhow, the straight-up wrong stuff should be fixed now. :)

[cjihrig]

LGTM. If the output is different between master and Node 8, then this might need to be adjusted during backporting.

[vsemozhetbyt]

I cannot see "Debugger attached" in any recent version for Windows, including the master and canary:

screenshot:

[vsemozhetbyt]

There is a small glimpse on the start, so I supposed this line was just rewritten on Windows. I've run this with redirection to a file and even have recorded a video and watched it frame by frame. There are some rewritten lines, but still, no "Debugger attached" among them:

node.8.1.2.v8-5.8.20170615.exe inspect test.js > debug.log:

�< Debugger listening on ws://127.0.0.1:9229/9ab1ed89-f254-4415-97eb-c99d61555806
< For help see https://nodejs.org/en/docs/inspector
�connecting to 127.0.0.1:9229 ... okdebug> �Break on start in test.js:1
> 1 (function (exports, require, module, __filename, __dirname) { global.x = 5;
  2 setTimeout(() => {
  3   debugger;
debug> 

[hybrist]

Interesting. Will investigate what's up on Windows. One possible answer could be stdout vs. stderr -

node/src/inspector_io.cc

Line 396 in 6e2c29b

fprintf(stderr, "Debugger attached.\n");

.

Given current information I suspect this is a bug (?) on Windows. The message should be printed.

[hybrist]

Landed in b647f04.