This seems noisy (both the output and the diff). Users almost certainly will never care about the array at the end. Couldn't you just add the piece that links to the debugging guide?

@cjihrig

Couldn't you just add the piece that links to the debugging guide?

Sure, my goal in the initial commit was to share a few options for review. A tricky part is that users may need the UUID or full ws://... URL if connecting manually.

I think we should at least keep both the the documentation link and the chrome URL. Also, we should err on the side of providing more help, even if it is at the cost of being too verbose.

I have an idea I am reluctant to mention because I feel it would be overkill, but I'll do it anyways. If we want to eliminate noise and be helpful, a solution would be to link to a single HTML page ( perhaps with URL parameters) which displays any dynamic links or configurations for various tools.

One observation I made was that people seem to be unaware of the automatic links in chrome://inspect and aren't that happy with having to copy&paste the URL (see the advent of chrome extensions that duplicate chrome://inspect). So I'm not sure printing the chrome-devtools:// url is doing anyone any favors. It seems to funnel people into a bad workflow.

Do we want to update this PR and remove the experimental warnings or would that require another PR?

@jkrems I'll update this one in next couple days, thanks!

@jkrems @ofrobots @eugeneo updated to an official proposal, PTAL.

This is per next steps in Diag WG meeting: https://github.com/nodejs/diagnostics/blob/master/wg-meetings/2017-03-23.md#wip-inspector-hint-text-update-11207

This removes the chrome-devtools:// URL and only provides a ws://... URL. The copy-pastability of the chrome-devtools URL has been raised in the above meeting; would it be possible for chrome://inspect to accept the ws://... URL and transform it to the chrome-devtools URL? That would actually make copy-pasting easier since the URL is shorter.

Thanks!

Chrome DevTools are looking at different options to help the users start debugging the Node (e.g. shorter/bookmarkable URL, easier discovery, etc) but there is no immediate solution that would be more convenient to copying the URL from the console to the browser address bar.

Even to copy/pasting the WS URL to chrome://inspect requires the users to read the guide and remember "chrome://inspect" URL itself. It is an extra step whenever the Node is restarted - and judging from the UUID introduction, this will be even bigger pain.

Removing the URL at this time will definitely break the workflow of many users. I believe it should be kept it a smoother workflow is implemented and is deployed in Chrome stable...

My personal vote would be for the ws://<host>:<ip>/<uuid> format that is implemented here. "Open this URL in Chrome" isn't a great experience past the very first interaction. I would be surprised if many users are using that flow and are remotely happy with it. From what I'm aware people are either migrating to Chrome extensions, use IDEs like vscode to start the node process, or go for chrome://inspect. All of these are reasonable, convenient workflows but none of them really needs a full DevTools URL printed to stderr.

(*) I have a particular bias against the DevTools URL because I keep hearing people complain about having to copy and paste the URL on every restart. They think it's the "normal"/"suggested"/"official" workflow and so they don't check the docs for better ways. I'd rather not keep re-posting the same answers to even more developers... ;)

@Trott @nodejs/ctc the following is where your opinions would be helpful, thanks! I think you can reflect these via approvals to this PR and/or rejections and comments in this thread. I tagged ctc-agenda cause I think a brief live discussion would be helpful. There's a possibility I might miss the meeting today cause of travel 😞 (will be back more consistently starting next week!), @jkrems any possibility you could attend the CTC meeting today as well to help explain if needed? Thanks!

Without further ado 😉 here's that explanation:

The current hint text (in master) is:

Debugger listening on 127.0.0.1:9229.
To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/eff03f13-55c9-4fef-8bf4-f938376ac9d6

The hint text proposed in this PR is:

Debugger listening on ws://127.0.0.1:9229/11cb1a9c-5994-4a83-a681-f4213b0fdd12
For help see https://nodejs.org/en/docs/guides/debugging_getting_started

The main questions to be reviewed by the CTC are:

1. Whether or not to include To start debugging...chrome-devtools://... in the hint text or remove it.
2. Whether to provide the entire ws://host:port/uuid URL or just host:port in the first line.

My opinion is that the message proposed in this PR is easier to read and understand, mostly avoids the >80 column overflow with the long chrome-devtools URL, (see e.g. #7141) and provides enough information to get started without being overly verbose.

Although the extra For help see... line isn't strictly necessary, I think it aligns with our spirit of being as helpful as possible to our users. It also helps address usability concerns due to removal of the DevTools URL. Finally, it's easier to update that doc for changes in clients rather than introduce changes here in the runtime (e.g. if Chrome DevTools itself introduces a new syntax).

Removing the chrome-devtools:// text will also reduce the somewhat incorrect association of Node/V8's Inspector with Chrome DevTools and other tools, reflected in issues such as #11591, #10410, #9382, and #8438; and as alluded to by @jkrems above (comment).

Including the UUID in the default output will also be helpful to some users, see #11496, #11701, #9185, and #10578. For the same reason prepending the scheme (i.e. ws) makes it more obvious that WebSocket rather than HTTP is the protocol in use.

Since Inspector is just now emerging from experimental status this change isn't yet semver-major, but I think it would be after 8.0.0, so want to land this before the final release, one of the reasons I tagged ctc-agenda.

Thanks for your help!

Cherry-picked update to node-inspect landed in #12363.

New CI: https://ci.nodejs.org/job/node-test-pull-request/7516/

I'm +1 on the proposed changed hint text in this PR.

any possibility you could attend the CTC meeting today as well to help explain if needed?

@joshgav I could join for the first couple of minutes but have some conflicting meetings. With the delay of the release (and some CTC members already chiming in here) it seems less urgent..?

Maybe we can get https://nodejs.org/en/inspector or similar rather than https://nodejs.org/en/docs/guides/debugging_getting_started?

Maybe we can get https://nodejs.org/en/inspector or similar rather than https://nodejs.org/en/docs/guides/debugging_getting_started?

+1. The debugging_getting_started guide indeed seem to be a big wall of text. A different doc with very clear links to how to open various different debuggers (VSCode, DevTools, etc.) would be a lot more usable.

From the @nodejs/website perspective, https://nodejs.org/en/docs/inspector might be slightly better information architecture than https://nodejs.org/en/inspector. Either is 👍 by me, FWIW.

I'm +1 for something like https://nodejs.org/en/docs/inspector. Seems better than the guide.

Removed lots of text from the doc per @ofrobots' feedback and moved to https://nodejs.org/en/docs/inspector in nodejs/nodejs.org#1216, PTAL.

Updated link in this PR too.

I'll land this once the updated doc lands in nodejs.org. If any are still opposed please comment now!

Thanks all. This PR landed in 6ade7f3.

The docs PR landed in nodejs/nodejs.org@13eaf4c