Uniform way to trigger debugger on first line

@roblourens

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)

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.

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.

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.

@sam-github

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.

@sam-github

@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"?

I think it's break as in breakpoint.

@Trott

@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

@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.

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

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?

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

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.

@refack

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.

@ChALkeR

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

@ChALkeR

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?

@refack

@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.

inspector: --debug* deprecation and invalidation

Navigation Menu

Repository navigation

Uniform way to trigger debugger on first line #12630

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

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Uniform way to trigger debugger on first line #12630

Description

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

Activity

refack commented on Apr 24, 2017

sam-github commented on Apr 24, 2017

gibfahn commented on Apr 24, 2017

gibfahn commented on Apr 24, 2017

refack commented on Apr 24, 2017

gibfahn commented on Apr 24, 2017

sam-github commented on Apr 25, 2017

Trott commented on Apr 25, 2017

MylesBorins commented on Apr 25, 2017

33 remaining items

Fishrock123 commented on May 10, 2017

refack commented on May 10, 2017

refack commented on May 10, 2017

hybrist commented on May 10, 2017

refack commented on May 10, 2017

Trott commented on May 14, 2017

joshgav commented on May 15, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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