Awesome! Thanks everyone that helped put all this together and made it possible!

@ofrobots I'm a bit late to the party so sorry if this has been covered in the other thread... Would this PR landing change anything in regards to the current debugger?

Great to see this come through. Looking forward to playing around with it.

@thealphanerd The old debugger is not affected, and still works as-is. v8_inspector debugger gets enabled only when the --inspect option is provided.

My initial reaction is that this is fantastic. Thank you.

@ofrobots

v8_inspector debugger gets enabled only when the --inspect option is provided.

It would be great if it could be enabled/disabled at runtime using a v8.debugOn/Off() js API call.

@ofrobots Why import the entire inspector?

Why import the entire inspector?

Was wondering that myself...

Why import the entire inspector?

What do you mean by entire inspector?

It would be great if it could be enabled/disabled at runtime using a v8.debugOn/Off() js API call.

Does present debugger allow that? We were aiming at feature parity before we start adding features. Enabling dynamically means that we would bind port at runtime. Other than that, debugger can be enabled/disabled at any moment, no technical limitations there.

Nice work!

So the intent is for this to get merged to v6 and then removed again at v7 when it's baked into V8? Why not just wait until v7 when it's built-in? Certainly it's valuable work and would benefit v6 greatly, but this is a rather large chunk of stuff to review only to remove it again in a few months.

What does the plan look like for merging with V8? I assume the user-facing surface of it would stay the same when we reach v7? (Other than maybe not needing the build flag anymore?)

What do you mean by entire inspector?

The second commit -> a7f339b

This PR is not bringing in the DevTools inspector. It only brings in the v8_inspector part, which is an implementation of the DevTools debug protocol.

It would be great if it could be enabled/disabled at runtime using a v8.debugOn/Off() js API call.

This would be a good follow-on. Once this PR lands, it would be easier to work on the ergonomics & integration.

but this is a rather large chunk of stuff to review only to remove it again in a few months.

The review is needed on 0995140. This integrates the inspector protocol into Node-core. This code is is not going to be removed in a few months. Once this is reviewed and merged, it would be an independent question whether this should merge into v6.x. Part of the answer depends on whether this is a semver major change.

The other, larger, commit is a dependency that is needed until the dependency merges upstream into V8. Here's the upstream repository: https://chromium.googlesource.com/chromium/src/third_party/WebKit/Source/platform/v8_inspector/. This commit, like other dependency rolls, doesn't really need an in-depth review.

EDIT: fix link.

Thanks so much for all this work! Really looking forward to having a "real"/modern debugger protocol for node.

I assume that since the --inspector flag already is disabled by default, it might be possible to enable --with-inspector by default during the lifetime of node 6? Getting a "real" debugger that is part of all the binary distributions of node as part of the next LTS would be great.

The above ("what will become the next LTS") is also, imo, a good reason for bringing it into node 6 and to not wait until all the inspector pieces landed in v8 itself.

Hmmm, when we were originally discussing this I was under the impression we'd only have the hooks for the v8 debugger but not actually ship the v8 debugger?

IIRC the v8 (chrome?) debugger is very version agnostic so there wasn't any great need for it to ship in core, and shipping in core is pretty awkward as we see with npm. e.g. you're never quite on the version you want to be. Plus it's a ton of extra source code.

This is assuming the v8/chrome debugger doesn't need native compilation, if it does, that is probably going to be a whole other issue.

Another question: is this intending to replace the default node debugger?

Hmmm, when we were originally discussing this I was under the impression we'd only have the hooks for the v8 debugger but not actually ship the v8 debugger?

This PR does not include the Devtools debugger. It only includes the debugger protocol implementation. When you run with --inspect you see the following on the command line:

chrome-devtools://devtools/remote/serve_file/@4604d24a75168768584760ba56d175507941852f/inspector.html?experiments=true&v8only=true&ws=localhost:5858/node

Chrome will load the version of inspector identified by the id, served from the DevTools web hosts. The only thing Node is doing, is implementing a debug server that 'talks' the protocol expected by the Devtools debugger.

Another question: is this intending to replace the default node debugger?

No.

Wow, I'm really surprised that it is this large given that it's just the hooks...

Ok, so it's the hooks + the protocol, that makes sense. Will have to spend some time digging into that second commit. The size is a bit concerning but not too bad.

BTW, there are other debuggers that already talk the same protocol, for example: https://github.com/Microsoft/vscode-chrome-debug. It is conceivable that these debuggers could be extended to support Node.js debugging.

Sorry, I was a bit vague. I meant to ask specifically about if the dependency would get removed in v7 (due to being integrated in V8).

Merging 0995140 seems reasonable to me. It's just a7f339b that I'm a bit wary of, since it'd be a bunch of churn to add it and then remove it again. Am I understanding the plan right? The dep get added in v6, then hopefully merged into V8 and removed again for probably v7?

FWIW, I'm leaning more toward just merging it for the sake of making debugging in v6 LTS much nicer. I'm just a bit unsure of the semver-minor-ness of this and the extra work to pull the dep in and maintain it, if we already know we're going to need to remove it again later and get it through the V8 dep.

@ofrobots ... are the jinja and markupsafe dependencies really necessary? What are those being used for? (I could keep digging and find out but figured it would be easier to ask ;-) ..)

If there is push back on a7f339b due to size, could it be brought in similar to the way we were handling icu before?

are the jinja and markupsafe dependencies really necessary?

those are build-time dependencies, we are using jinja to generate native protocol dispatcher and protocol data structures off protocol.json.

I cant print to chrome console on Windows. Macbook works fine. Anyone else having this issue?

how to autostart chrome devtool when i write node --inspect app.js ?

@uMaxmaxmaximus I use this Chrome extension: https://chrome.google.com/webstore/detail/nodejs-v8-inspector/lfnddfpljnhbneopljflpombpnkfhggl

@FredyC

Extention throw error:

Could not launch debugger
Invalid devtools URL in
[ { "description": "node.js instance", "devtoolsFrontendUrl": "chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/74dec2d8-aca4-4725-85af-f292cb39ad13", "faviconUrl": "https://nodejs.org/static/favicon.ico", "id": "74dec2d8-aca4-4725-85af-f292cb39ad13", "title": "./build/server", "type": "node", "url": "file://C:_localhost_taxi_build_server", "webSocketDebuggerUrl": "ws://127.0.0.1:9229/74dec2d8-aca4-4725-85af-f292cb39ad13" } ]

@uMaxmaxmaximus Sorry, I am not the author of that extension and I don't think this is a right place to try to solve the issue ... https://github.com/continuationlabs/node-v8-inspector

@FredyC
I've tried it, it does not work unfortunately. Maybe there is some way to intercept the link of std.output using node.js? Then I would have written a module that automatically opens a browser to this link.

Maybe link active debugger put to global.__inspectorUrl__ ?
Or create debugger object like this, to control debug from runtime script:

global.debug = {
  url: 'bla bla',
  port: 'bla bla',
  next: function(){ [native code] },
  stepInto: function(){ [native code] },
  e.t.c
}

@uMaxmaxmaximus I don't know, it works for me (on Windows as well). There is another alternative you might try ... https://github.com/jaridmargolin/inspect-process

@uMaxmaxmaximus http://june07.com/nim will manage DevTools (including auto launch).

Hi @ofrobots and team. Can we debug Node.js code written in TypeScript (.ts file) rather than regular JS?

@alysson-pina it should not matter as long as V8 can run the code. One thing you may need is to generate in-line source maps.

Where do you see the error? How do you run the Node to debug TypeScript?

So the final conclusion is that there is no way to debug node written in TypeScript?

@rafraph This is probably not the place to ask how to debug TypeScript. Lookup Debugging with Source Maps, I'm sure there are lots of tutorials. If you get stuck, ask on https://StackOverflow.com

I'm not asking how to debug typescript. From reading this thread it seems that debugging node written in TypeScript is not supported in Chrome. After @alysson-pina asked his question, it seems from the answers that this is not supported, so I just want to know if this is the final conclusion.
BTW, I asked it in StackOverflow.com and someone send me to here, so this is an infinite loop :-)

What do you mean by "the same"? the traspiled code is totaly different and not really readable.

@rafraph And that's where source maps comes in :) #6792 (comment)

Is it true that live debug is impossible with this feature? I mean, debug an app with nodemon, for example, when nodemon restarts the server on every save Ctrl + S?

Currently Chrome Devtools breaks down when I save changes in my app:

How to deal with it? How to make Devtools reconnect automatically?