Node: Add option to break on start of specific file

[Ginden]

Use case: debugging applications run by certain tools (test runners etc.)
Issue: --inspect-brk starts debugging in tool, not application code; walking over numerorous function calls before applications starts is cumbersome
Proposed solution: add flag --inspect-brk-on to be used like:

$ node --inspect-brk-on=./lib/index.js $(which serverless) invoke --function main # break happens on first line of ./lib/index.js

[refack]

There are two workaround for this:

1. use the debugger keyword
2. set a breakpoint with setBreakpoint('./lib/index.js', 1) and cont

[Ginden]

I know there are workarounds.

Though - setBreakpoint won't work with V8 Inspector as far as I know.
And placing and removing debugger requires certain amount of work too - but is repeatable work to be performed on every debugging session.

[Fishrock123]

It would probably be generally easier and more portable to just use --inspect-brk and then put a breakpoint where you want it in the app from the inspector / chrome dev tools / etc.

[Ginden]

@Fishrock123 As far as I know you have to wait for app files to be required and tools can do nontrivial amount of work before requiring actual application code.

[refack]

IMHO it's an interesting feature. Maybe even expand it to a generic way to set multiple BreakPoints via the CLI, independent of which files are actually loaded (most IDEs support this feature).
/cc @nodejs/diagnostics

[jkrems]

Though - setBreakpoint won't work with V8 Inspector as far as I know.

It should work. We have explicit tests for setting breakpoints in files that haven't been required yet. The way it works is that we set those breakpoints via urlRegex. This should work with the built-in debugger & also with things like VSCode/Chrome Devtools/etc..

This sounds like an IDE feature, not necessarily a node core feature.

[refack]

This sounds like an IDE feature, not necessarily a node core feature.

There is a use-case where you want to use "remote debugging", that is when you start the debugee, not the IDE. What I do in those cases is either use --debug-brk, then attach, set a breakpoint, and continue. Alternativly I put a debugger statement in the code.
I would be beneficial to have a --set-breakpoint=url:line CLI arg, but it might not be worth the effort...

[jkrems]

The reason why I say "IDE feature" is because in those cases I generally set more than just one breakpoint and the IDE/devtools makes sure they survive multiple restarts etc.. So it seems weird for node itself to "mess" with some of the breakpoints, especially given that the protocol doesn't have a "list breakpoints" method.

[refack]

Ref: https://github.com/nodejs/node/pull/13228

[Trott]

@nodejs/v8-inspector @nodejs/diagnostics Is this a feature we are likely to add?

If the answer is "yes", perhaps we can consider adding a help wanted label? If someone is available to mentor someone on implementing this feature, perhaps we can add a mentor available label too.

If "no", we should probably indicate that in a comment and close this.

[pavelfeldman]

I think the request is valid and does not require much work. Deferring the labels to @ofrobots.

Feature-wise, there is a long tail of features like this. You can imagine settings for the blackboxing, breaking or not breaking on exceptions, recording performance profile, etc etc.

All these features, including --inspect-brk-on and --set-breakpoint assume that we start moving parts of the debugger front-end into Node and expect it to still work with the external front-end. Hardly a sustainable path.

The way we could make it work is if debugging front-end was accessing the command line arguments of node and was interpreting them:

node --inspect-brk --inspect-args='--start-at=foo.js --set-breakpoint=foo.js:45'

Front-end would attach, interpret this command line and initialize its state.

We could then shorten it to:

node --inspect-args='--start-at=foo.js --set-breakpoint=foo.js:45'

All we need from the node side is to not yell at the user when they pass --inspect-args. Those are already available via process.execArgv.

[mike-kaufman]

Agree w/ @jkrems here, namely that this feature falls under the "debugger client" - whatever debugger client you're using has the capability to set breakpoints at arbitrary locations, so moving this into node core feels like the wrong factoring to me.

Also, if the user is using some debugger, then this capability is already available to them. Am I missing something?

[refack]

Seem like this falls outside of the expected node-core scope. Several client do implement this.

[refack]

Put into https://github.com/nodejs/node/projects/13 backlog