Uniform way to trigger debugger on first line #12630

refack · 2017-04-24T21:58:33Z

Ref: #12364

Have --inspect --debug-brk as a uniform way to trigger debug on first line
1. Restore the --inspect --debug-brk combo to v7+v8 (inspector: restore --debug-brk alias #12580)
2. Does it stay undocumented? Or maybe it should become the primary option and remove --inspect-brk (re: inspector: make debug an alias for inspect #11441)
  (IMHO if we keep it --debug-brk, --inspect-brk will probably never be used)
3. Will the combo be valid in node8?
4. What do we do with --debug-port / inspect-port?
5. In light of these, consider what to mark as deprecated.
6. Since v6 and v7 requires the combo --inspect[=port] --debug-brk[=port] is specifying port on both args a valid invocation, and in that case which port wins?
Have --inspect-brk as a uniform way to trigger debug on first line
1. Keep the --inspect --debug-brk combo in v7 alone (deprecation notice yes/no) (i.e. don't land src: Remove support for --debug #12197 in v7)
2. port the --inspect-brk alias to v6 (inspector: enable --inspect-brk in v6 #12615)
  [new comment] this will make --inspect-break a feature of recent versions of 6.x, but it can't change the past: versions of 6.x will always exist without this feature, and so will not be debuggable by third-party tooling [without special treatment]
3. for v4 it's irrelevant since it's a different protocol and other means of detection and handling is necessary
Help the users adapt to our plan:
1. Help fix VSCode properly, make it compatible with our current and future plans (/cc @roblourens Ref: [wip] implement runtimeExecutable version detection microsoft/vscode-node-debug2#100)
2. Make sure JetBrains handle node8 nightlies (/cc @ulitink @segrey youtrack#WEB-26568)

User feedback

I'm trying to get more feedback from @roblourens and JetBrains, so you could make the best decision.

Quote from youtrack#WEB-26568
Comment from @roblourens regression: 3rd party debuggers are incompatible with node8 nighlies #12364 (comment)

P.S. at present WebStorm and IDEA based IDEs can't trigger debug in node8 nightlies (nor can VSCode)

The text was updated successfully, but these errors were encountered:

refack · 2017-04-24T21:59:58Z

After hearing from the IDE vendors, IMHO we should forget about --inspect-brk, it won't get adopted, and just keep --debug-brk permanently.
Protocol detection & resolution is done in orthogonal ways anyway.

sam-github · 2017-04-24T22:12:54Z

I'm OK with keeping --debug-brk permanently as the flag meaning "break-on-first-line" (too bad it wasn't called that originally). It seems analogous (to me) with how node debug starts the inspector in most recent. In which case, we don't have to backport anything, we just start the deprecation process for --inspect-brk (so long, barely had time to know you).

I'm also OK with backporting --inspect-brk.

gibfahn · 2017-04-24T22:36:08Z

It seems to me that if you ignore the --inspect --debug-brk combo, then the situation becomes much more simple. Going forward we want a flag that means "start the debugger and break on the first line", and we have two options. The pros and cons are:

Choice	Pros	Cons
`--inspect-brk`	`--inspect`+`--inspect-brk` makes sense	it's another option to remember, `--debug-brk` already exists
`--debug-brk`	Old flag, new protocol, just keeps working. Also more intuitive if you don't know or care what the inspector is.	May be confusing that `--debug-brk` on v6 !== `--inspect --debug-brk` on v6 and !== `--debug-brk` on v7

Thinking about this further, I'd be +1 for abandoning --inspect-brk and sticking with --debug-brk. By Node 10 or 11, no-one will (hopefully) remember or need to care about the difference between the two protocols, we'll just have the one. And at that point having --debug-brk mean "start a debugger and break" seems like the natural choice.

If we're going to do that then we should not backport --inspect-brk, and we should re-add --debug-brk to master.

EDIT: I'd also say that the number of times I've used the inspector without the brk option is very small, I'd say this is really the default option for a user.

gibfahn · 2017-04-24T22:38:01Z

I'm OK with keeping --debug-brk permanently as the flag meaning "break-on-first-line" (too bad it wasn't called that originally).

@sam-github the thing is that you're not supposed to do --inspect --debug-brk, you're just supposed to do --debug-brk, which debugs and breaks. So it actually seems pretty well named to me. The --inspect --debug-brk thing is a temporary aberration caused by having two debug protocols in one version of Node.

refack · 2017-04-24T22:42:31Z

@sam-github the thing is that you're not supposed to do --inspect --debug-brk, you're just supposed to do --debug-brk, which debugs and breaks. So it actually seems pretty well named to me. The --inspect --debug-brk thing is a temporary aberration caused by having two debug protocols in one version of Node.

If you look at the code it's actually syntactic sugar for three operations:

Choose protocol
Set port
Break on first line

I think ideally it would have only been used by users, while vendors used the three explicit args
--inspect --brake-on-first --debugger-port=5599

BTW: should it be "break" of "brake"?

gibfahn · 2017-04-24T22:52:01Z

I think it's break as in breakpoint.

sam-github · 2017-04-25T03:08:29Z

@Trott @eugeneo thoughts? doesn't matter to much too me which we do, but we need to do one or the other, allow --debug-brk in all versions, or backport --inspect-break.

Trott · 2017-04-25T04:09:38Z

@Trott @eugeneo thoughts? doesn't matter to much too me which we do, but we need to do one or the other, allow --debug-brk in all versions, or backport --inspect-break.

I'm happy to defer to the judgment of @nodejs/diagnostics and @nodejs/LTS on this.

MylesBorins · 2017-04-25T07:48:56Z

I think we should first define the best ux for debugging with a break, and then work backwards.

refack · 2017-04-25T13:14:09Z

The IDE vendors are now making it clear a breaking change in args will not be backported:

JetBrains: #12364 (comment)

VScode: #12364 (comment)

(the 👍s is mine)

Seems we'll have to keep --inspect --debug-brk for the time being. So IMHO --inspect-brk and inspect-port are redundant...

Fishrock123 · 2017-04-25T15:08:06Z

My personal, pedantic vote is --break-on-first-line.

Alternatively, --{debug|inspect}-pause probably make more sense.

... I suppose the ship has already sailed on that though, so maybe we should just keep --debug-brk because it is essentially just adding a debugger; which shares a similar name-ism.

sam-github · 2017-04-25T15:16:12Z

I'm OK with @refack and @Fishrock123 's suggestion of keeping --debug-brk and --debug-port indefinitely as the documented CLI options.

What about the briefly existing --inspect-brk and --inspect-port, leave them indefinitely, but undocumented? Or should we start the deprecation process (doc deprecate for 8.x, runtime deprecate for 9.x, remove in 10.x)?

Fishrock123 · 2017-04-25T15:27:14Z

I think --debug-port should be done away with in favor of --inspect-port, fwiw.

roblourens · 2017-04-25T15:33:19Z

I wish we had added --inspect-brk from the beginning - I agree at least that it looks nicer and is consistent with --debug-brk. But I also wonder, in the future when the old protocol is long forgotten, will --inspect be a good name? If someone is looking for an option to "debug", will they discover it? I wonder where it will make sense to add --debug as an alias at some point.

sam-github · 2017-04-25T15:36:25Z

@Fishrock123 so, you want node debug, --inspect, --inspect-port, and --debug-brk?

jkrems · 2017-04-25T15:37:48Z

--inspect-brk is the only way to start the mostly-desired debug behavior with one single flag. I really don't think we should remove it. I'd be fine with keeping --debug-brk/--debug-port around as a deprecated features as long as it's only valid in combination with --inspect. I'm not sure why anyone in the "glorious future" would prefer --inspect --debug-brk --debug-port=1234 over --inspect-brk=1234.

Fishrock123 · 2017-04-25T15:38:45Z

No I would rather it all just be inspect but I guess we might have to make a compromise somewhere.

jasnell · 2017-04-25T15:49:55Z

I would prefer --inspect, --inspect-port and --inspect-brk. We can add --inspect-port and --inspect-brk as aliases of --debug-brk and --debug-port in LTS streams, and --debug-brk and --debug-port as undocumented, deprecated aliases of their --inspect-* counterparts going forward.

gibfahn · 2017-04-25T16:06:04Z

I'm not sure why anyone in the "glorious future" would prefer --inspect --debug-brk --debug-port=1234 over --inspect-brk=1234.

@jkrems You wouldn't do that, in Node 8 node --debug-brk=1234 would be identical to node --inspect-brk=1235 (which is why we only want to keep one). So the question is --debug-brk or --inspect-brk.

sam-github · 2017-04-25T16:58:49Z

We can have it all be inspect, we just have to backport --inspect-brk, and support --debug-brk going forward for a while. Maybe the CTC needs to hash this out f2f.

jkrems · 2017-04-25T17:18:31Z

@gibfahn But then a tool that passes only --debug-brk={myPort} would see widely different behavior between {any other version of node} and node 8. And there wouldn't be any good indication for why it broke. Having the same set of command line flags enable entirely different protocols is a bit too evil for my taste.

refack · 2017-04-25T22:17:04Z

I'm not sure why anyone in the "glorious future" would prefer --inspect --debug-brk --debug-port=1234 over --inspect-brk=1234

@jkrems I think we have two use-cases:

Automated tools: who might prefer explicit 3 part arg:
1.protocol - --inspect/debug
2.should-stop-on-first yes/no - --debug-brk (if we could give it a better name we should)
3.which port --debug-port=1234
IMHO this combination can be formed in a simpler if-else process.
CLI user - who probably prefer the shortcut --inspect-brk=1234, can make complex decisions and adapt to new syntax.

refack · 2017-05-01T14:26:35Z

@billti @roblourens @prigara we would like to hear your latest opinions on two things:

Is there consensus that --inspect --debug-brk is necessary for compatibility with existing tools?
What is your preference for future syntax?
1. adopt single argument --inspect-brk[=[host:]port], and backport it?
2. adopt the explicit three argument combo (protocol, port, is-to-break)
  --inspect --debug-port=HOST:XXX --debug-brk?
3. keep the 2 argument combo --inspect --debug-brk for the foreseeable future?

jkrems · 2017-05-01T14:40:43Z

I thought the general agreement was:

We need to keep --inspect --debug-brk working for the time being.
For better usability & less confusion --inspect-brk is still a good thing and - imo - should definitely be ported to node 6.

This means future tools (after node 6 phased out) won't have to deal with any "why are halve of the flags called --inspect and the other half --debug", users get CLI flags as nice & succinct as the original --debug/--debug-brk, and older IDEs will work against node 8.

refack · 2017-05-01T14:51:04Z

@jkrems I also think there is wide agreement on 1
As for 2 I have an assumption the vendors will not adopt --inspect-brk, that's why I asked them.
As for individual CLI users, I have no strong opinion, just the preference that we have a single set of well-documented arguments (so we might need to yield with the vendors 🤷)

jkrems · 2017-05-01T15:10:01Z

@refack The thing is: node --inspect-brk is a lot less annoying to type than node --inspect --debug-brk. I don't quite get why we would "willfully" regress on the CLI usability, especially given that on current master node --inspect-brk already works. I get keeping the --debug-brk alias around. But not the other part.

P.S.: Even if today's vendors won't use --inspect-brk, in 1 or 2 years different people will build different tools targeting different (read: newer) versions of node. And I'd be surprised if they pick --inspect --debug-brk over --inspect-brk if they have the choice.

roblourens · 2017-05-01T15:46:22Z

I agree with @jkrems. As long as --inspect --debug-brk works for the foreseeable future, I'm happy. --inspect-brk seems good to keep as well.

refack · 2017-05-01T15:56:37Z

I kind of agree.
As I see it, the message should be is: for v6 & v7 we had to fast transition our debug protocol. Sorry for confusing our users with new names. node8 has only one debugger and only one (official) way to trigger it (undocumented backward compatibility aliases are a "secret" necessary evil).
What I hope for node8 is to make --inspect-brk == --debug-brk since there is no other debugger.

My personal preference is to make the debug* variants the official variants (IMHO the inspect moniker was as internal name that got leaked to userland).

P.S. voice your opinion on our internal issue #12768

jkrems · 2017-05-01T16:19:13Z

As pointed out elsewhere in the thread, going back to --debug (or --debug-brk w/o --inspect) anytime soon is pretty evil. The same command line option combination shouldn't trigger 2 completely different protocols across different versions of node. Especially when we have node 6 and 7 where the two protocols coexist.

--inspect* is for the "V8 inspector protocol". --debug* is for the "V8 debugging protocol". There are good reasons to use different flags for different protocols. --inspect --debug-brk is an unfortunate weirdness for historical reasons but we should try to reduce confusion for future releases.

refack · 2017-05-01T17:48:44Z

I want to reduce bikeshedding...
IMHO The main function of --inspect* and --debug* is to start a debugger.
inspect and debug are different protocols, and that's secondary. Similar to --inspect:9999 and --nspect:1234 listen to different ports.
@jkrems if you still strongly disagree, I yield (pending words from the vendors).

I think we can all agree that the docs and node --help should only display one set (or something with [deprecated] as necessary).

jkrems · 2017-05-01T18:25:39Z

I think we can all agree that the docs and node --help should only display one set (or something with [deprecated] as necessary).

Yes, those official parameters are --inspect* for the inspect protocol and, for older versions of node, --debug* for V8's old protocol. For versions that support both, node --help would display both. For versions that only support one, it would display one. If somebody explicitly passes --xyz to start one of the protocols, they want to start one specific protocol that their client supports. Otherwise they would click a button in their IDE which in turn would pass specific flags to expose the protocol it expects.

For me the fact that we'll have to keep --inspect --debug-brk around to support "early" adopters of the inspector protocol is the internal detail that we shouldn't leak into our docs & --help output.

refack · 2017-05-10T16:51:12Z

@Fishrock123 during the transition when both protocols were avalible, all vendors had a version update that was compatible with both. There was no back-porting :(

As mentioned above by all vendors, current versions will not be able to debug node8, and they firmly state that they will not backport. So users will have to upgrade/buy a new IDE

refack · 2017-05-10T16:53:07Z

All current versions are compatible with both protocols

Fishrock123 · 2017-05-10T16:54:11Z

Cross-posting from: #12580 (comment)

-1, I don't really see the point in keeping it when --debug-brk was going to be removed in a major.

I would be for having it print out a notice to use --inspect-brk though.

the vendors can't/won't backport --inspect-brk so all current IDEs will not be albe to debug node8

If they can "back-port" --inspect and detect that it is a version that needs the inspector, what is stopping them for doing the same for the similar *-brk flag?

refack · 2017-05-10T16:57:05Z

I'll try to sum:

current versions of IDEs work with both protocols
vendors have been exclusively using --inspect --debug-brk to trigger inspector
if we don't restore alias current IDEs will not work with node8
Give vendors a year to shift

refack · 2017-05-10T17:10:46Z

the vendors can't/won't backport --inspect-brk so all current IDEs will not be albe to debug node8

If they can "back-port" --inspect and detect that it is a version that needs the inspector, what is stopping them for doing the same for the similar *-brk flag?

#12630 (comment)

They all had a release cycle while both protocols were available. Unfortunately they used --inspect --debug-brk to trigger inspector. That's hardcoded logic in all current versions.

jkrems · 2017-05-10T17:12:28Z

If they can "back-port" --inspect and detect that it is a version that needs the inspector, what is stopping them for doing the same for the similar *-brk flag?

To elaborate on what @refack already said: What was stopping them was that --inspect-brk unfortunately didn't exist yet when they started to work on the integration. So they couldn't do the "right" thing.

refack · 2017-05-10T17:16:07Z

If I understand correctly CTC agreed to restore --inspect --debug-brk as alias to --inspect-brk, pending @ChALkeR's investigating an issue.

Trott · 2017-05-14T03:24:03Z

Pinging @ChALkeR: Did you gather the information you needed to gather? Are we prepared to move forward with restoring --inspect --debug-brk? Or not yet?

joshgav · 2017-05-15T21:54:05Z

@refack

CTC agreed to restore --inspect --debug-brk as alias to --inspect-brk, pending @ChALkeR's investigating an issue.

This is my understanding as well, and #12949 accomplishes that (and more).

@jkrems

going back to --debug (or --debug-brk w/o --inspect) anytime soon is pretty evil. The same command line option combination shouldn't trigger 2 completely different protocols across different versions of node.

I agree, and in fact I think this might be @ChALkeR's primary concern.

Based on this, #12949 should not add back --debug at all.

On the other hand, it could be helpful to our users to print a friendly message when --debug is specified in 8.x. I don't think that should be part of #12949 but would be appropriate for another PR.

PR-URL: nodejs#12949 Fixes: nodejs#12364 Fixes: nodejs#12630 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>

PR-URL: #12949 Fixes: #12364 Fixes: #12630 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>

refack added debugger inspector Issues and PRs related to the V8 inspector protocol lts Issues and PRs related to Long Term Support releases. meta Issues and PRs related to the general management of the project. labels Apr 24, 2017

refack mentioned this issue Apr 24, 2017

LTS Meeting April 24th - 5 pm EST nodejs/Release#201

Closed

refack mentioned this issue Apr 24, 2017

regression: 3rd party debuggers are incompatible with node8 nighlies #12364

Closed

MylesBorins added the ctc-review label Apr 24, 2017

AndreasMadsen added the diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. label Apr 25, 2017

sam-github mentioned this issue Apr 27, 2017

inspector: restore --debug-brk alias #12580

Closed

4 tasks

Trott mentioned this issue May 1, 2017

Node.js Foundation Core Technical Committee (CTC) Meeting 2017-05-03 nodejs/CTC#117

Closed

Trott mentioned this issue May 8, 2017

Node.js Foundation Core Technical Committee (CTC) Meeting 2017-05-10 nodejs/CTC#120

Closed

Trott added the ctc-agenda label May 10, 2017

refack mentioned this issue May 10, 2017

inspector,cli: restore --debug and --inspect --debug-brk with deprecation warnings #12949

Merged

4 tasks

joshgav removed ctc-agenda diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. meta Issues and PRs related to the general management of the project. labels May 15, 2017

refack added a commit to refack/node that referenced this issue May 29, 2017

inspector: --debug* deprecation and invalidation

16689e3

PR-URL: nodejs#12949 Fixes: nodejs#12364 Fixes: nodejs#12630 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>

refack closed this as completed in #12949 May 29, 2017

jasnell pushed a commit that referenced this issue May 29, 2017

inspector: --debug* deprecation and invalidation

010f864

PR-URL: #12949 Fixes: #12364 Fixes: #12630 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jan Krems <[email protected]>

Uniform way to trigger debugger on first line #12630

Uniform way to trigger debugger on first line #12630

Comments

refack commented Apr 24, 2017

Have --inspect --debug-brk as a uniform way to trigger debug on first line

Have --inspect-brk as a uniform way to trigger debug on first line

Help the users adapt to our plan:

User feedback

refack commented Apr 24, 2017 • edited Loading

sam-github commented Apr 24, 2017

gibfahn commented Apr 24, 2017 • edited Loading

gibfahn commented Apr 24, 2017

refack commented Apr 24, 2017

gibfahn commented Apr 24, 2017

sam-github commented Apr 25, 2017

Trott commented Apr 25, 2017

MylesBorins commented Apr 25, 2017 via email • edited by gibfahn Loading

refack commented Apr 25, 2017 • edited Loading

Fishrock123 commented Apr 25, 2017 • edited Loading

sam-github commented Apr 25, 2017

Fishrock123 commented Apr 25, 2017

roblourens commented Apr 25, 2017 • edited Loading

sam-github commented Apr 25, 2017

jkrems commented Apr 25, 2017

Fishrock123 commented Apr 25, 2017

jasnell commented Apr 25, 2017

gibfahn commented Apr 25, 2017

sam-github commented Apr 25, 2017

jkrems commented Apr 25, 2017

refack commented Apr 25, 2017

refack commented May 1, 2017

jkrems commented May 1, 2017 • edited Loading

refack commented May 1, 2017

jkrems commented May 1, 2017 • edited Loading

roblourens commented May 1, 2017

refack commented May 1, 2017

jkrems commented May 1, 2017 • edited Loading

refack commented May 1, 2017 • edited Loading

jkrems commented May 1, 2017

refack commented May 10, 2017

refack commented May 10, 2017

Fishrock123 commented May 10, 2017 • edited Loading

refack commented May 10, 2017 • edited Loading

refack commented May 10, 2017

jkrems commented May 10, 2017

refack commented May 10, 2017

Trott commented May 14, 2017

joshgav commented May 15, 2017

Have `--inspect --debug-brk` as a uniform way to trigger debug on first line

Have `--inspect-brk` as a uniform way to trigger debug on first line

refack commented Apr 24, 2017 •

edited

Loading

gibfahn commented Apr 24, 2017 •

edited

Loading

MylesBorins commented Apr 25, 2017 via email •

edited by gibfahn

Loading

refack commented Apr 25, 2017 •

edited

Loading

Fishrock123 commented Apr 25, 2017 •

edited

Loading

roblourens commented Apr 25, 2017 •

edited

Loading

jkrems commented May 1, 2017 •

edited

Loading

jkrems commented May 1, 2017 •

edited

Loading

jkrems commented May 1, 2017 •

edited

Loading

refack commented May 1, 2017 •

edited

Loading

Fishrock123 commented May 10, 2017 •

edited

Loading

refack commented May 10, 2017 •

edited

Loading