Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inspector,doc: update hint text, add guide #8978

Closed
wants to merge 3 commits into from

Conversation

joshgav
Copy link
Contributor

@joshgav joshgav commented Oct 7, 2016

Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

inspector, doc

Description of change

Updates hint text for --inspect to 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

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. inspector Issues and PRs related to the V8 inspector protocol labels Oct 7, 2016
specification of the debugger's capabilities.

When started with the `node debug` command, Node.js runs the specified user script in a
child process with the `--debug-brk` flag and starts a debugger client which connects to that process.
Copy link
Member

@jasnell jasnell Oct 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: long lines

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

jasnell commented Oct 7, 2016

LGTM with a few formatting nits.

@eugeneo
Copy link
Contributor

eugeneo commented Oct 7, 2016

LGTM

@mscdex
Copy link
Contributor

mscdex commented Oct 7, 2016

I guess technically this should be blocked until #8979 has landed?

@mscdex mscdex added the blocked PRs that are blocked by other issues or PRs. label Oct 7, 2016
@joshgav
Copy link
Contributor Author

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!

@joshgav
Copy link
Contributor Author

joshgav 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:

  • Fixes up hint text a bit more and moves chrome-devtools URL to referenced guide.
  • Adds more info to guide on getting started with Chrome DevTools or VS Code, and placeholders for a couple more.
  • Fixes inspector test for new text.

@joshgav joshgav changed the title inspector,doc: update hint text, add guide [WIP] inspector,doc: update hint text, add guide Oct 11, 2016
@joshgav
Copy link
Contributor Author

joshgav commented Oct 15, 2016

@ofrobots

Is there an urgency to removing the copy-pastable link?

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!

Copying the link is still less friction-ful than opening a webpage with a guide.

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 (node debug) to be more generic?

@gibfahn
Copy link
Member

gibfahn commented Oct 15, 2016

@joshgav Agreed that we should make it clear that a number of tools can be used with --inspect, but wouldn't the answer then be to include text that explains that there are other options? Is the worry that users will see the URL and ignore the rest of the text?

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 node --inspect manually? Would they even see this message?

Let me know if I'm misunderstanding!

@rvagg rvagg force-pushed the master branch 2 times, most recently from c133999 to 83c7a88 Compare October 18, 2016 17:02
@joshgav joshgav removed the blocked PRs that are blocked by other issues or PRs. label Oct 19, 2016
@joshgav joshgav dismissed eugeneo’s stale review October 19, 2016 14:49

Intended as neutral, not rejection.

@joshgav
Copy link
Contributor Author

joshgav commented Oct 19, 2016

@gibfahn

would the answer then be to include text that explains that there are other options?

This was the first option suggested in nodejs/diagnostics#68. We determined that this would clutter up the output too much and be unhelpful.

Also can the URL be used in other debugging tools?

This was the third option suggested - to standardize the scheme (i.e. currently chrome-devtools://) to work with other tools too. We decided this is a worthwhile long-term goal but wouldn't be possible in the near-term.

Would they even see this message?

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#8978
Fixes: nodejs#7182
Reviewed-By: <tbd>
Reviewed-By: <tbd>

* The following table clarifies the implications of various diag-related flags:

<table cellpadding=0 cellspacing=0>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing all this HTML makes me cringe a bit. What about using github's table markdown syntax?

@evanlucas
Copy link
Contributor

I don't think we should land this until (stable) chrome allows listing debuggable node targets via chrome://inspect. So, -1 from me for landing in v7

@joshgav
Copy link
Contributor Author

joshgav commented Oct 19, 2016

@mscdex

What about using github's table markdown syntax?

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
Copy link
Member

I also think we don't need to rush it into 7.

@auchenberg
Copy link

The community has now build inspect-process, which adds a inspect cli command that starts node --inspect and Chrome DevTools with the right url.

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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this no longer works, given that /node is now a random UUID?

@jkrems jkrems mentioned this pull request Dec 18, 2016
2 tasks
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"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can assume stderr supports ANSI escape codes.

@joshgav
Copy link
Contributor Author

joshgav commented Feb 6, 2017

debugging guide moved to nodejs.org website location: nodejs/nodejs.org#1131

@joshgav joshgav mentioned this pull request Feb 6, 2017
4 tasks
@joshgav
Copy link
Contributor Author

joshgav commented Feb 6, 2017

hint text update discussion moved to #11207

@joshgav
Copy link
Contributor Author

joshgav commented Feb 6, 2017

closing in favor of new, separate PRs:

@joshgav joshgav closed this Feb 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. inspector Issues and PRs related to the V8 inspector protocol
Projects
None yet
Development

Successfully merging this pull request may close these issues.