Uh oh!
There was an error while loading. Please reload this page.
inspector,doc: update hint text, add guide - #8978
Conversation
There was a problem hiding this comment.
Fixed the long lines outside of tables and long URLs. Will switch to an embedded HTML table for better control. Not sure what to do about the long URLs...
jasnell
commented
Oct 7, 2016
LGTM with a few formatting nits. |
eugeneo
commented
Oct 7, 2016
LGTM |
I guess technically this should be blocked until #8979 has landed? |
joshgav
commented
Oct 8, 2016
I need to fix a test for this too but wanted to get consensus on the text. The chrome-devtools URL is still in the hint text at the moment, but I think we should move it to the guide too. @eugeneo is the URL with the hash what we should put there? Or something different? Thanks! |
af1430a to
8c9a1e5Comparejoshgav
commented
Oct 11, 2016
Code part here including tests should now be done, PTAL. Still need to figure out how/where to put the guide, see nodejs/nodejs.org#901. Latest push:
|
joshgav
commented
Oct 15, 2016
The main reason I think is to ensure users are aware that other tools can also be used with --inspect. Some users may mistakenly think only Chrome DevTools can be used, which would be unfortunate as we encourage and expand the Node tools ecosystem. Not to take anything away from CDT, which certainly is a great option!
Agreed, but does this mean some one-liner must always be included in the hint? Also, is it the responsibility of Node itself to remove this friction, or is it something to leave to the ecosystem? Perhaps the one-liner should refer to the built-in debugger ( |
@joshgav Agreed that we should make it clear that a number of tools can be used with Also can the URL be used in other debugging tools? As I understand it the Chrome Debugging Protocol is going to be standardised as the protocol for node debugging. Presumably in the future browser based ones will open via a (generic) URL, and IDE based ones will usually be run directly from the IDE. If (for example) someone was debugging their node app through VS Code, would they not just use the debugging tab in VS Code itself, rather than running Let me know if I'm misunderstanding! |
c133999 to
83c7a88Comparejoshgav
commented
Oct 19, 2016
This was the first option suggested in nodejs/diagnostics#68. We determined that this would clutter up the output too much and be unhelpful.
This was the third option suggested - to standardize the scheme (i.e. currently
The text is part of console output (actually stderr) so shows up in IDEs and when processes are started from the terminal. Ultimately this PR is based on option 2 in nodejs/diagnostics#68, which we decided was the most straightforward to implement now: use a generic URL in the hint text and provide more detail in a linked wiki. At this point I believe we have consensus on moving to the new text I proposed here eventually, but the question is when. I believe we should make this change now before we cut v7. @nodejs/ctc - would like the CTC's thoughts on this - should we land now or later? If later, what milestone or date should we target? |
Updates hint text for --inspect to be more generic. Instructions for various debugger clients moved into a referenced guide. PR-URL: nodejs#8978Fixes: nodejs#7182 Reviewed-By: <tbd> Reviewed-By: <tbd>
| * The following table clarifies the implications of various diag-related flags: | ||
| <table cellpadding=0 cellspacing=0> |
There was a problem hiding this comment.
Seeing all this HTML makes me cringe a bit. What about using github's table markdown syntax?
evanlucas
commented
Oct 19, 2016
I don't think we should land this until (stable) chrome allows listing debuggable node targets via |
joshgav
commented
Oct 19, 2016
Would love that and did so originally, but lines exceeded 80 columns. Also I couldn't do a multiline cell. Would be happy to try switching back. |
mhdawson
commented
Oct 19, 2016
I also think we don't need to rush it into 7. |
auchenberg
commented
Nov 7, 2016
The community has now build inspect-process, which adds a I see this as an argument for removing chrome-specific URL in Node core. |
| * **Option 2**: Paste the following URL in Chrome, | ||
| replacing the `ws` parameter with your hostname and port as needed: | ||
| `chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node` |
There was a problem hiding this comment.
I guess this no longer works, given that /node is now a random UUID?
| port, GetWsUrl(port, id).c_str()); | ||
| fprintf(stderr, "Debugger listening on \x1B[33mws://%s\x1b[0m\n" | ||
| "* Info on connecting at" | ||
| "\x1B[33mhttps://nodejs.org/en/docs/guides/debugging\x1B[0m.\n" |
There was a problem hiding this comment.
I don't think we can assume stderr supports ANSI escape codes.
joshgav
commented
Feb 6, 2017
debugging guide moved to nodejs.org website location: nodejs/nodejs.org#1131 |
joshgav
commented
Feb 6, 2017
hint text update discussion moved to #11207 |
joshgav
commented
Feb 6, 2017
closing in favor of new, separate PRs:
|
Checklist
make -j8 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
inspector, doc
Description of change
Updates hint text for
--inspectto a generic websockets URL and reference to more info on interface and available clients. Includes an initial draft of the guide with that info.Tests for new message included too.
Fixes#7182
/cc @nodejs/diagnostics