Inspecting Node.js with Chrome DevTools #2546

Closed
yury-s opened this Issue Aug 25, 2015 · 89 comments

Comments

Projects
None yet
@yury-s

yury-s commented Aug 25, 2015

Objective

We’ve been thinking about providing unified debugger support across various v8 embedders. One natural approach to that is to reuse Chrome DevTools and provide its JS debugger, performance and memory profiler functionality to Node.js users. What we aim for Node is what we have for Chrome for Android. You basically go to chrome://inspect on a stable version of Chrome and it debugs your running Node instance. You might need to override / specify ports to both if you want them to be non-default. The rest is behind the scenes.

Internal design

DevTools is comprised of the two major components: Frontend providing UI and Backend that instruments inspected application. Frontend is essentially a web application that communicates to the Backend via remote debugging protocol and nothing prevents it from connecting to Node.js instead of Chrome. To support that we’ll need to extract parts of debugger and profiler functionality from Blink into a separate project that would implement DevTools remote debugging protocol. Let’s call the project v8-inspector. Node.js could then expose the protocol to the Frontend over a WebSocket connection.

Proof of concept

I’ve created a prototype demonstrating this approach:

https://github.com/yury-s/v8-inspector - implementation of DevTools protocol for debugger, performance and memory profilers. I started with forking Blink and then removed dependencies that wouldn’t make sense in Node.js. There is definitely more work to be done but I believe this is good enough as a proof of concept.
https://github.com/yury-s/io.js/tree/remote-debugger - io.js clone that uses the project decribed above and ws module to allow using DevTools Frontend for debugging/profiling.

Local Node debugging scenario with custom ports would look like this:

  1. Start Node with --remote-debugging-port=9222 command-line flag
  2. Start Chrome with --remote-debugging-targets=localhost:9222 command-line flag
  3. Navigate Chrome to chrome:inspect to see list of inspectable Node.js targets

Longer term

Long-term solution would be to have both Blink and Node.js use the same native v8-inspector library linked against v8. DevTools Frontend development would continue in Blink. For each version of v8-inspector there is a compatible version of DevTools Frontend served from the cloud. This is how it works with Android debugging at the moment: when the user opens DevTools for Chrome running on Android, the desktop browser loads a version of DevTools UI corresponding to the version of Chrome running on Android and forwards all traffic from the device to that Frontend.

Open questions

Before moving forward with this approach and investing into Blink refactorings necessary for extracting common code into its own library we’d like to collect some feedback on whether Node.js community would be interested in that. In particular, is there an interest in integrating such debugger library into Node.js core?

  • This will require compiling Node with the v8-inspector library and providing Node.js-specific implementation of interfaces required by the debugger.
  • Remote debugging protocol will be exposed to third party Node.js modules as a simple API similar to what is available for Chrome extensions (https://developer.chrome.com/extensions/debugger). Client of such API should run on a separate thread not to interfere with JavaScript in the inspected Node application. In the prototype all debugger events are forwarded from the main thread to a node instance running on a separate thread.
  • Implementing transport for the protocol. It can be a module that would use the debug API described above and send protocol commands over WebSocket. E.g. in the prototype it is a simple web server based on ‘ws’ module: https://github.com/yury-s/io.js/blob/remote-debugger/lib/remote_debugging_server.js. Bundling this module with the core would enable zero-conf rich devtools experience (on par with Chrome’s DevTools).
  • As the project evolves it will require adding new instrumentation to use some new features such as asynchronous call stacks. On the DevTools side we’ll be providing generic API that would work for both Blink and Node.js
  • There is some maintenance cost related to the debugger if Node.js decides to ship with it but I don’t expect it to be much higher than for the current debugger that includes debugger-agent.cc. Ideally, v8-inspector would be included as part of the v8 checkout and the obsolete debugging protocol implemented by v8 would be removed, but that is not a done deal yet.
@ofrobots

This comment has been minimized.

Show comment
Hide comment
Contributor

ofrobots commented Aug 25, 2015

@bmeck

This comment has been minimized.

Show comment
Hide comment
Member

bmeck commented Aug 25, 2015

@Qard

This comment has been minimized.

Show comment
Hide comment
@Qard

Qard Aug 25, 2015

Member

/cc @nodejs/tracing

Member

Qard commented Aug 25, 2015

/cc @nodejs/tracing

@thlorenz

This comment has been minimized.

Show comment
Hide comment
@thlorenz

thlorenz Aug 25, 2015

Contributor

I did some related work a while ago: https://github.com/thlorenz/debugium

Implementing the protocol is the easy part. However trying to reuse code from chromium that communicates with v8 turned out to be non-trivial.
Things are quite coupled in there as I realized when I tried to unfuddle things.

For anyone working on this https://github.com/thlorenz/chromium-remote-debugging-proxy may come in useful as it allows watching the messages sent between chrome DevTools and the debugged instance which helps in understanding the protocol used.

Contributor

thlorenz commented Aug 25, 2015

I did some related work a while ago: https://github.com/thlorenz/debugium

Implementing the protocol is the easy part. However trying to reuse code from chromium that communicates with v8 turned out to be non-trivial.
Things are quite coupled in there as I realized when I tried to unfuddle things.

For anyone working on this https://github.com/thlorenz/chromium-remote-debugging-proxy may come in useful as it allows watching the messages sent between chrome DevTools and the debugged instance which helps in understanding the protocol used.

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Aug 25, 2015

To add a few items…

This project brings all of the DevTools's JS features to Node. That includes:

  • the sampling profiler with flame chart, top-down and bottom-up tree views
  • memory heap snapshot capture and viewing
  • memory allocation profiler
  • JS debugger with breakpoints, step-out/in/over. Asynchronous stacks
  • Experimental efforts around Step into Async, Promises view, etc.

Moving forward with this would make the current node-inspector codebase somewhat redundant, but we'd like to work with @bajtos, @3y3 and friends on making sure the experience of launching a debugging/profiling session with these tools is smooth and enjoyable.

@thlorenz

At one point I was told that the chrome team was going to take that on, but afaik that never materialized.

This ticket is the materialization of that work. ;) @yury-s is an engineer on Chrome and owns the JS debugging tools and how they interface with V8.

To add a few items…

This project brings all of the DevTools's JS features to Node. That includes:

  • the sampling profiler with flame chart, top-down and bottom-up tree views
  • memory heap snapshot capture and viewing
  • memory allocation profiler
  • JS debugger with breakpoints, step-out/in/over. Asynchronous stacks
  • Experimental efforts around Step into Async, Promises view, etc.

Moving forward with this would make the current node-inspector codebase somewhat redundant, but we'd like to work with @bajtos, @3y3 and friends on making sure the experience of launching a debugging/profiling session with these tools is smooth and enjoyable.

@thlorenz

At one point I was told that the chrome team was going to take that on, but afaik that never materialized.

This ticket is the materialization of that work. ;) @yury-s is an engineer on Chrome and owns the JS debugging tools and how they interface with V8.

@thlorenz

This comment has been minimized.

Show comment
Hide comment
@thlorenz

thlorenz Aug 25, 2015

Contributor

@paulirish Awesome! Happy this is finally happening :)

Contributor

thlorenz commented Aug 25, 2015

@paulirish Awesome! Happy this is finally happening :)

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 25, 2015

Contributor

Does --remote-debugging-port=9222 bind to localhost or 0.0.0.0? Could it be made configurable? Much usage will come from debugging remote processes.

Will we have to integrate the same type of code into our JS, along with our C++, like in v8/src/promise.js:

  if (DEBUG_IS_ACTIVE) {
    %DebugPromiseEvent({ promise: promise, status: status, value: value });
  }

Having this w/o LTS support reduces its utility in node. As such it will become a maintenance burden across 4 or 5 active branches. Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

Also in regards to LTS support, I assume that there isn't indefinite support of Chrome to debugger API support. Or am I wrong?

Contributor

trevnorris commented Aug 25, 2015

Does --remote-debugging-port=9222 bind to localhost or 0.0.0.0? Could it be made configurable? Much usage will come from debugging remote processes.

Will we have to integrate the same type of code into our JS, along with our C++, like in v8/src/promise.js:

  if (DEBUG_IS_ACTIVE) {
    %DebugPromiseEvent({ promise: promise, status: status, value: value });
  }

Having this w/o LTS support reduces its utility in node. As such it will become a maintenance burden across 4 or 5 active branches. Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

Also in regards to LTS support, I assume that there isn't indefinite support of Chrome to debugger API support. Or am I wrong?

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 25, 2015

Does --remote-debugging-port=9222 bind to localhost or 0.0.0.0? Could it be made configurable? Much usage will come from debugging remote processes.

It can be bound to any interface that we want, I don't see any issues with that (except security). Chrome already accepts both host and port as values of --remote-debugging-targets and the host may well be remote one.

It makes sense to differentiate between transport and the debugger backend implementing the remote debugging protocol. Same debugger implementation can be used with different types of connections similar to how it works in Chrome at the moment where various transports are used to transfer DevTools traffic depending on the inspected target:

  1. Chrome IPC in case of Chrome embedded DevTools.
  2. Web Socket when connecting to remote Chrome instance.
  3. Adb when connecting to Chrome and WebView running on Android devices.

Will we have to integrate the same type of code into our JS, along with our C++, like in v8/src/promise.js:

If Node uses alternative implementation of Promises and wants to leverage debugging capabilities provided by v8-inspector then yes, you will need to provide corresponding instrumentation that way or another. v8-inspector is going to have C++ API so you'll need at least one binding to notify the debugger. The call will go through the v8-inspector C++ API not through some internal v8 API.

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

I'm afraid not, as it would require making v8-inspector work with such old releases of v8. This is a non-goal for the project. As I mentioned, the idea is to have particular version of v8-inspector compatible with particular version of v8 API. If v8 is updated, v8-inspector will likely need to be updated as well.

Also in regards to LTS support, I assume that there isn't indefinite support of Chrome to debugger API support. Or am I wrong?

At the moment, there is no official v8 debugger API which would be well-supported. There is a set of C++ methods in v8-debug.h as well as debug context which provides access to the debugger internals. This is one of the issues we'd like to address with v8-inspector. It should become a recommended way to debug v8. Eventually we'd like to drop most of v8/src/debug/debug.js and prohibit using the debug context directly.

Such approach would leave us the freedom of changing remote debugging protocol without committing to its backward compatibility as there will always be a version of Chrome DevTools compatible with given version of the backend. There are already two types of protocol commands: public and hidden. Public ones are those for which we commit to backward compatibility. We're hesitant on adding more public commands as it limits our development pace.

In terms of LTS, similar to v8 we don't want to commit to keeping the API stable as it would be too restrictive. What we can do is to follow the same public API compatibility as v8 does (or at least declares): https://code.google.com/p/v8-wiki/wiki/Source#V8_public_API_compatibility

Since Blink is going to use v8-inspector too, we'll have to keep it up to date with latest v8 API changes. Should we make any breaking changes they will be easy to detect in nightly builds and can be reverted. On our side we'll have to make sure that changes to v8-inspector API would be made in a non-breaking manner, follow the same public API deprecation policy as v8 does and the new APIs would work for Node too, not only for Chrome.

Will this work for you?

yury-s commented Aug 25, 2015

Does --remote-debugging-port=9222 bind to localhost or 0.0.0.0? Could it be made configurable? Much usage will come from debugging remote processes.

It can be bound to any interface that we want, I don't see any issues with that (except security). Chrome already accepts both host and port as values of --remote-debugging-targets and the host may well be remote one.

It makes sense to differentiate between transport and the debugger backend implementing the remote debugging protocol. Same debugger implementation can be used with different types of connections similar to how it works in Chrome at the moment where various transports are used to transfer DevTools traffic depending on the inspected target:

  1. Chrome IPC in case of Chrome embedded DevTools.
  2. Web Socket when connecting to remote Chrome instance.
  3. Adb when connecting to Chrome and WebView running on Android devices.

Will we have to integrate the same type of code into our JS, along with our C++, like in v8/src/promise.js:

If Node uses alternative implementation of Promises and wants to leverage debugging capabilities provided by v8-inspector then yes, you will need to provide corresponding instrumentation that way or another. v8-inspector is going to have C++ API so you'll need at least one binding to notify the debugger. The call will go through the v8-inspector C++ API not through some internal v8 API.

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

I'm afraid not, as it would require making v8-inspector work with such old releases of v8. This is a non-goal for the project. As I mentioned, the idea is to have particular version of v8-inspector compatible with particular version of v8 API. If v8 is updated, v8-inspector will likely need to be updated as well.

Also in regards to LTS support, I assume that there isn't indefinite support of Chrome to debugger API support. Or am I wrong?

At the moment, there is no official v8 debugger API which would be well-supported. There is a set of C++ methods in v8-debug.h as well as debug context which provides access to the debugger internals. This is one of the issues we'd like to address with v8-inspector. It should become a recommended way to debug v8. Eventually we'd like to drop most of v8/src/debug/debug.js and prohibit using the debug context directly.

Such approach would leave us the freedom of changing remote debugging protocol without committing to its backward compatibility as there will always be a version of Chrome DevTools compatible with given version of the backend. There are already two types of protocol commands: public and hidden. Public ones are those for which we commit to backward compatibility. We're hesitant on adding more public commands as it limits our development pace.

In terms of LTS, similar to v8 we don't want to commit to keeping the API stable as it would be too restrictive. What we can do is to follow the same public API compatibility as v8 does (or at least declares): https://code.google.com/p/v8-wiki/wiki/Source#V8_public_API_compatibility

Since Blink is going to use v8-inspector too, we'll have to keep it up to date with latest v8 API changes. Should we make any breaking changes they will be easy to detect in nightly builds and can be reverted. On our side we'll have to make sure that changes to v8-inspector API would be made in a non-breaking manner, follow the same public API deprecation policy as v8 does and the new APIs would work for Node too, not only for Chrome.

Will this work for you?

@3y3

This comment has been minimized.

Show comment
Hide comment
@3y3

3y3 Aug 25, 2015

@thlorenz ,

Implementing the protocol is the easy part. However trying to reuse code from chromium that communicates with v8 turned out to be non-trivial.

At current iteration node-inspector tries to inject some parts of Chrome debugger API to app.
There exists some outdated experiments with InjectedScriptSource.js and DebuggerScript.js from blink source.

v8-debug has experimental method enableWebkitProtocol
(but work in progress)

Main problem of this experiments - compatibility:

  1. Compatibility of js codebase - chrome debugger uses all latest js features implemented in v8 (generators, arrow functions, for of) (I say here about InjectedScriptSource.js and DebuggerScript.js)
  2. Compatibility of features (c++ codebase) - async call stack, workers, network debugging etc. This is also described in issue open questions

As the project evolves it will require adding new instrumentation to use some new features such as asynchronous call stacks. On the DevTools side we’ll be providing generic API that would work for both Blink and Node.js

For this reason I also worried about @trevnorris questions:

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

@paulirish ,

Moving forward with this would make the current node-inspector codebase somewhat redundant

I will be happy, if node-inspector will change his main target from "supporting compatibility with DevTools" to something like "extended debugging environment for nodejs"

@yury-s , are you want to backport async call stack from chrome to node? And some other features?

I'd like to think about v8-inspector.h like about current v8-debug.h in v8. His provide main api to implement debugger into nodejs, but also provides entry points for external developers.
In context of v8-debug.h main entry point is getDebugContext.
So I'd like to see more api for external developers =)

3y3 commented Aug 25, 2015

@thlorenz ,

Implementing the protocol is the easy part. However trying to reuse code from chromium that communicates with v8 turned out to be non-trivial.

At current iteration node-inspector tries to inject some parts of Chrome debugger API to app.
There exists some outdated experiments with InjectedScriptSource.js and DebuggerScript.js from blink source.

v8-debug has experimental method enableWebkitProtocol
(but work in progress)

Main problem of this experiments - compatibility:

  1. Compatibility of js codebase - chrome debugger uses all latest js features implemented in v8 (generators, arrow functions, for of) (I say here about InjectedScriptSource.js and DebuggerScript.js)
  2. Compatibility of features (c++ codebase) - async call stack, workers, network debugging etc. This is also described in issue open questions

As the project evolves it will require adding new instrumentation to use some new features such as asynchronous call stacks. On the DevTools side we’ll be providing generic API that would work for both Blink and Node.js

For this reason I also worried about @trevnorris questions:

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

@paulirish ,

Moving forward with this would make the current node-inspector codebase somewhat redundant

I will be happy, if node-inspector will change his main target from "supporting compatibility with DevTools" to something like "extended debugging environment for nodejs"

@yury-s , are you want to backport async call stack from chrome to node? And some other features?

I'd like to think about v8-inspector.h like about current v8-debug.h in v8. His provide main api to implement debugger into nodejs, but also provides entry points for external developers.
In context of v8-debug.h main entry point is getDebugContext.
So I'd like to see more api for external developers =)

@3y3

This comment has been minimized.

Show comment
Hide comment

3y3 commented Aug 25, 2015

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 25, 2015

Contributor

@yury-s Thank you for the comprehensive response.

If Node uses alternative implementation of Promises and wants to leverage debugging capabilities provided by v8-inspector then yes

Our process.nextTick() emulates the micro task queue. This and our handling of timers would most likely require insertion.

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

I'm afraid not, as it would require making v8-inspector work with such old releases of v8. This is a non-goal for the project.

While I understand, it's also unfortunate. Our main stable release is 6 month. Taking into account V8's rapid release cycle I will make the assumption that the same API could break before that is over. If we can't guarantee support for at least the 6 months of latest stable then I'm afraid that it won't do us any good.

Beyond that, saying it would be available for the 6 months of stable but not for the 18 months of LTS would need to have serious discussion as to whether bringing it is still viable. For the time I'm ignoring the additional 12 months a release will be in maintenance. Which brings full support to 3 years.

I do hope we can work out these issues, as having this available would be very helpful.

Contributor

trevnorris commented Aug 25, 2015

@yury-s Thank you for the comprehensive response.

If Node uses alternative implementation of Promises and wants to leverage debugging capabilities provided by v8-inspector then yes

Our process.nextTick() emulates the micro task queue. This and our handling of timers would most likely require insertion.

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

I'm afraid not, as it would require making v8-inspector work with such old releases of v8. This is a non-goal for the project.

While I understand, it's also unfortunate. Our main stable release is 6 month. Taking into account V8's rapid release cycle I will make the assumption that the same API could break before that is over. If we can't guarantee support for at least the 6 months of latest stable then I'm afraid that it won't do us any good.

Beyond that, saying it would be available for the 6 months of stable but not for the 18 months of LTS would need to have serious discussion as to whether bringing it is still viable. For the time I'm ignoring the additional 12 months a release will be in maintenance. Which brings full support to 3 years.

I do hope we can work out these issues, as having this available would be very helpful.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 25, 2015

For this reason I also worried about @trevnorris questions:

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

No. See my reply above.

@yury-s , are you want to backport async call stack from chrome to node? And some other features?

As Paul Irish wrote above the project will come with all debugging features available in Chromium. Async call stacks is not an exception. There is a generic API resembling the one described in this MSDN article which needs to be called from appropriate places where we'd like to capture async call stacks. I can help with adding such instrumentation to Node but we'll need some person knowledgeable better than me to identify places where the hooks should be added.

I'd like to think about v8-inspector.h like about current v8-debug.h in v8. His provide main api to implement debugger into nodejs, but also provides entry points for external developers.
In context of v8-debug.h main entry point is getDebugContext.

This is a good way to think about v8-inspector. Ideally, we should be able to drop v8-debug.h in favor of v8-inspector. This would make the API more explicit and allow to provide better support for it.

yury-s commented Aug 25, 2015

For this reason I also worried about @trevnorris questions:

Is it even possible that this API is integrated in a V8 release that's 1-2 years old?

No. See my reply above.

@yury-s , are you want to backport async call stack from chrome to node? And some other features?

As Paul Irish wrote above the project will come with all debugging features available in Chromium. Async call stacks is not an exception. There is a generic API resembling the one described in this MSDN article which needs to be called from appropriate places where we'd like to capture async call stacks. I can help with adding such instrumentation to Node but we'll need some person knowledgeable better than me to identify places where the hooks should be added.

I'd like to think about v8-inspector.h like about current v8-debug.h in v8. His provide main api to implement debugger into nodejs, but also provides entry points for external developers.
In context of v8-debug.h main entry point is getDebugContext.

This is a good way to think about v8-inspector. Ideally, we should be able to drop v8-debug.h in favor of v8-inspector. This would make the API more explicit and allow to provide better support for it.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 25, 2015

While I understand, it's also unfortunate. Our main stable release is 6 month. Taking into account V8's rapid release cycle I will make the assumption that the same API could break before that is over. If we can't guarantee support for at least the 6 months of latest stable then I'm afraid that it won't do us any good.

How does this work with v8 at the moment? There may be 4 or 5 major v8 releases in 6 months which means there may be a lot of breaking changes. Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

I do hope we can work out these issues, as having this available would be very helpful.

I hope so too.

yury-s commented Aug 25, 2015

While I understand, it's also unfortunate. Our main stable release is 6 month. Taking into account V8's rapid release cycle I will make the assumption that the same API could break before that is over. If we can't guarantee support for at least the 6 months of latest stable then I'm afraid that it won't do us any good.

How does this work with v8 at the moment? There may be 4 or 5 major v8 releases in 6 months which means there may be a lot of breaking changes. Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

I do hope we can work out these issues, as having this available would be very helpful.

I hope so too.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2015

Contributor

How does this work with v8 at the moment? There may be 4 or 5 major v8 releases in 6 months which means there may be a lot of breaking changes.

Once a major release branch is cut from master the V8 minor is no longer updated on that branch.

Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

From what I've read, it wouldn't. It doesn't make sense for us to integrate an API that will break so quickly. It's an added disadvantage since Google is insistent that no one have older versions of Chrome installed. If we were allowed to do that then it might be possible to simply use the corresponding Chrome version with a given node release.

Contributor

trevnorris commented Aug 26, 2015

How does this work with v8 at the moment? There may be 4 or 5 major v8 releases in 6 months which means there may be a lot of breaking changes.

Once a major release branch is cut from master the V8 minor is no longer updated on that branch.

Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

From what I've read, it wouldn't. It doesn't make sense for us to integrate an API that will break so quickly. It's an added disadvantage since Google is insistent that no one have older versions of Chrome installed. If we were allowed to do that then it might be possible to simply use the corresponding Chrome version with a given node release.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Aug 26, 2015

Member

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

I think it would also be very important that all the instrumentation hooks we need for async are there - and that integration when running non js modules in node works (reasonably) well. Of course, userland hooks might also be interesting (so people can signal to the debugger things they want it to ignore, for instance - C# has this and it's very useful).

Huge +1 for the idea by the way.

Member

benjamingr commented Aug 26, 2015

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

I think it would also be very important that all the instrumentation hooks we need for async are there - and that integration when running non js modules in node works (reasonably) well. Of course, userland hooks might also be interesting (so people can signal to the debugger things they want it to ignore, for instance - C# has this and it's very useful).

Huge +1 for the idea by the way.

@auchenberg

This comment has been minimized.

Show comment
Hide comment
@auchenberg

auchenberg Aug 26, 2015

This is great! Glad to see this is moving forward.

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

As I understand it, the debugger back-end is separate from the core via v8-inspector, and since it would implement the Chrome Remote Debugging Protocol over WebSocket and HTTP, the debugger back-end would be compatible with external front-ends like Chrome DevTools App (based upon Electron)

By having a runtime/protocol version we will be able to match the front-end with the back-end. Eventually this would need to use some kind of feature detection, but that's further out in the future, as I see it.

This is great! Glad to see this is moving forward.

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

As I understand it, the debugger back-end is separate from the core via v8-inspector, and since it would implement the Chrome Remote Debugging Protocol over WebSocket and HTTP, the debugger back-end would be compatible with external front-ends like Chrome DevTools App (based upon Electron)

By having a runtime/protocol version we will be able to match the front-end with the back-end. Eventually this would need to use some kind of feature detection, but that's further out in the future, as I see it.

@Qard

This comment has been minimized.

Show comment
Hide comment
@Qard

Qard Aug 26, 2015

Member

Yeah, the only way I see this working is shipping the UI as an electron app with each release, or ensuring backwards compatibility in the protocol long enough to support the LTS releases.

I think backwards compatibility for the dev tools should, in theory, be easier than V8 itself. It's only the protocol that is important here. I don't expect anyone should be touching the API outside of core, so node core doesn't need to worry about API compatibility.

Member

Qard commented Aug 26, 2015

Yeah, the only way I see this working is shipping the UI as an electron app with each release, or ensuring backwards compatibility in the protocol long enough to support the LTS releases.

I think backwards compatibility for the dev tools should, in theory, be easier than V8 itself. It's only the protocol that is important here. I don't expect anyone should be touching the API outside of core, so node core doesn't need to worry about API compatibility.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2015

Contributor

@yury-s Meant to ask, how much do you think the actual debugging API that connect client to process would change? If that itself doesn't change much, or can be fixed more easily over time, then we'd be much closer to having a workable solution.

Contributor

trevnorris commented Aug 26, 2015

@yury-s Meant to ask, how much do you think the actual debugging API that connect client to process would change? If that itself doesn't change much, or can be fixed more easily over time, then we'd be much closer to having a workable solution.

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Aug 26, 2015

Member

@benjamingr @Qard from the OP:

For each version of v8-inspector there is a compatible version of DevTools Frontend served from the cloud. This is how it works with Android debugging at the moment: when the user opens DevTools for Chrome running on Android, the desktop browser loads a version of DevTools UI corresponding to the version of Chrome running on Android and forwards all traffic from the device to that Frontend.

Doesn't it mean that one could use the latest Chrome and still be able to debug any version of Node.js using an old API ?

Member

targos commented Aug 26, 2015

@benjamingr @Qard from the OP:

For each version of v8-inspector there is a compatible version of DevTools Frontend served from the cloud. This is how it works with Android debugging at the moment: when the user opens DevTools for Chrome running on Android, the desktop browser loads a version of DevTools UI corresponding to the version of Chrome running on Android and forwards all traffic from the device to that Frontend.

Doesn't it mean that one could use the latest Chrome and still be able to debug any version of Node.js using an old API ?

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Aug 26, 2015

Member

@targos I'd much prefer it if it was possible to run the debugger without accessing code served from the cloud live. Node would have no control over which versions are supported and how - nor would it be able to easily edit the code (unless node starts serving it). I think it would be preferable to have a standalone app.

Member

benjamingr commented Aug 26, 2015

@targos I'd much prefer it if it was possible to run the debugger without accessing code served from the cloud live. Node would have no control over which versions are supported and how - nor would it be able to easily edit the code (unless node starts serving it). I think it would be preferable to have a standalone app.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2015

Contributor

Node isn't going to control what tools are used to communicate with the debugger API regardless. I'm not sure how some companies would feel about needing an internet connection to debug processes on their local network, but I'd say that sounds like a promising solution.

Contributor

trevnorris commented Aug 26, 2015

Node isn't going to control what tools are used to communicate with the debugger API regardless. I'm not sure how some companies would feel about needing an internet connection to debug processes on their local network, but I'd say that sounds like a promising solution.

@Qard

This comment has been minimized.

Show comment
Hide comment
@Qard

Qard Aug 26, 2015

Member

Yeah, not sure how I feel about a service out on the net somewhere having
direct access to the VM my code is running in. I'd definitely prefer the
standalone app.
On Aug 26, 2015 12:22 AM, "Benjamin Gruenbaum" notifications@github.com
wrote:

@targos https://github.com/targos I'd much prefer it if it was possible
to run the debugger without accessing code served from the cloud live. Node
would have no control over which versions are supported and how - nor would
it be able to easily edit the code (unless node starts serving it). I think
it would be preferable to have a standalone app.


Reply to this email directly or view it on GitHub
#2546 (comment).

Member

Qard commented Aug 26, 2015

Yeah, not sure how I feel about a service out on the net somewhere having
direct access to the VM my code is running in. I'd definitely prefer the
standalone app.
On Aug 26, 2015 12:22 AM, "Benjamin Gruenbaum" notifications@github.com
wrote:

@targos https://github.com/targos I'd much prefer it if it was possible
to run the debugger without accessing code served from the cloud live. Node
would have no control over which versions are supported and how - nor would
it be able to easily edit the code (unless node starts serving it). I think
it would be preferable to have a standalone app.


Reply to this email directly or view it on GitHub
#2546 (comment).

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Aug 26, 2015

Contributor

Would the scope include things like PageAgent.reload to restart a node process from inside the devtools or the NetworkAgent/ConsoleAgent/...? If not, then there's definitely still a lot of value in node-inspector & friends.

Contributor

jkrems commented Aug 26, 2015

Would the scope include things like PageAgent.reload to restart a node process from inside the devtools or the NetworkAgent/ConsoleAgent/...? If not, then there's definitely still a lot of value in node-inspector & friends.

@Spy-Seth

This comment has been minimized.

Show comment
Hide comment
@Spy-Seth

Spy-Seth Aug 26, 2015

This feature could also lead to use the Firefox devtools with node thought the valence project 👍 👍 👍

This feature could also lead to use the Firefox devtools with node thought the valence project 👍 👍 👍

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

@trevnorris :

@yury-s Meant to ask, how much do you think the actual debugging API that connect client to process would change? If that itself doesn't change much, or can be fixed more easily over time, then we'd be much closer to having a workable solution.

This one is stable. For basic debugging support it is as simple as this:

class FrontendChannel {
    virtual void sendToFrontend(const String& message) = 0;
}
class Backend {
    void connectFrontend(FrontendChannel* channel);
    void disconnectFrontend();
    void dispatchMessageFromFrontend(const String& message);
}

See https://github.com/yury-s/v8-inspector/blob/embedded-in-io/Source/v8inspector/V8Inspector.h#L33 and https://github.com/yury-s/v8-inspector/blob/embedded-in-io/Source/core/inspector/InspectorFrontendChannel.h

The messages are strings that are opaque to Node, all parsing and dispatching of the protocol messages is performed by v8-inspector itself.

Once a major release branch is cut from master the V8 minor is no longer updated on that branch.

At that point v8-inspector is also branched along with v8. Also we know exact revision of the front-end that is compatible with that v8-inspector and can use it for debugging this particular release of v8 (embedded in Node, Chrome or something else). At the moment v8 branching is consistent with Chrome so we should always have good front-end that is capable of debugging that v8 version. More details below.

@trevnorris

Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

From what I've read, it wouldn't. It doesn't make sense for us to integrate an API that will break so quickly. It's an added disadvantage since Google is insistent that no one have older versions of Chrome installed. If we were allowed to do that then it might be possible to simply use the corresponding Chrome version with a given node release.

@benjamingr

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

@targos

Doesn't it mean that one could use the latest Chrome and still be able to debug any version of Node.js using an old API ?

@targos exactly. We already allow debugging Chrome 38 that can be found on many Android devices by connecting to it with Chrome 46. The way it works is for each Blink revision we have a copy of the front-end sources served from the cloud. After that we ask inspected target which front-end revision should be used for debugging and load it from the cloud into devtools window. E.g. to connect to chrome 44.0.2403.133 we use this link https://chrome-devtools-frontend.appspot.com/serve_rev/@199588/inspector.html

In case of Android remote debugging we load the front-end into a browser window that has special devtools bindings providing connection to the browser on the device over USB. This API is backwards compatible so that we could load old front-ends.

In case of Node we don't even have to do this since we can connect via plain WebSocket . The front-end can be loaded as a normal page and remote target url can be passed as 'ws' param: https://chrome-devtools-frontend.appspot.com/serve_rev/@199588/inspector.html?ws=localhost:9222/node This will work except for some features that require more privileges than regular web page can have, e.g. access to local file system. Loading as a privileged DevTools front-end provides better user experience.

yury-s commented Aug 26, 2015

@trevnorris :

@yury-s Meant to ask, how much do you think the actual debugging API that connect client to process would change? If that itself doesn't change much, or can be fixed more easily over time, then we'd be much closer to having a workable solution.

This one is stable. For basic debugging support it is as simple as this:

class FrontendChannel {
    virtual void sendToFrontend(const String& message) = 0;
}
class Backend {
    void connectFrontend(FrontendChannel* channel);
    void disconnectFrontend();
    void dispatchMessageFromFrontend(const String& message);
}

See https://github.com/yury-s/v8-inspector/blob/embedded-in-io/Source/v8inspector/V8Inspector.h#L33 and https://github.com/yury-s/v8-inspector/blob/embedded-in-io/Source/core/inspector/InspectorFrontendChannel.h

The messages are strings that are opaque to Node, all parsing and dispatching of the protocol messages is performed by v8-inspector itself.

Once a major release branch is cut from master the V8 minor is no longer updated on that branch.

At that point v8-inspector is also branched along with v8. Also we know exact revision of the front-end that is compatible with that v8-inspector and can use it for debugging this particular release of v8 (embedded in Node, Chrome or something else). At the moment v8 branching is consistent with Chrome so we should always have good front-end that is capable of debugging that v8 version. More details below.

@trevnorris

Assuming that v8-inspector is shipped as part of v8 and its API is defined in /include/v8-inspector.h (which would be ideal case for us long-term) how would that work with Node?

From what I've read, it wouldn't. It doesn't make sense for us to integrate an API that will break so quickly. It's an added disadvantage since Google is insistent that no one have older versions of Chrome installed. If we were allowed to do that then it might be possible to simply use the corresponding Chrome version with a given node release.

@benjamingr

I think it is very important that the debugger ships with node as a standalone (rather than connected via chrome://somename for compatibility issues, I still want to be able to easily debug io.js 3.0 when Chrome gets 5 versions ahead. Something like an atom/electron wrapper over a specific version of Chromium would be ideal and it would also solve the compatibility issues.

@targos

Doesn't it mean that one could use the latest Chrome and still be able to debug any version of Node.js using an old API ?

@targos exactly. We already allow debugging Chrome 38 that can be found on many Android devices by connecting to it with Chrome 46. The way it works is for each Blink revision we have a copy of the front-end sources served from the cloud. After that we ask inspected target which front-end revision should be used for debugging and load it from the cloud into devtools window. E.g. to connect to chrome 44.0.2403.133 we use this link https://chrome-devtools-frontend.appspot.com/serve_rev/@199588/inspector.html

In case of Android remote debugging we load the front-end into a browser window that has special devtools bindings providing connection to the browser on the device over USB. This API is backwards compatible so that we could load old front-ends.

In case of Node we don't even have to do this since we can connect via plain WebSocket . The front-end can be loaded as a normal page and remote target url can be passed as 'ws' param: https://chrome-devtools-frontend.appspot.com/serve_rev/@199588/inspector.html?ws=localhost:9222/node This will work except for some features that require more privileges than regular web page can have, e.g. access to local file system. Loading as a privileged DevTools front-end provides better user experience.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

@benjamingr :

I'd much prefer it if it was possible to run the debugger without accessing code served from the cloud live. Node would have no control over which versions are supported and how - nor would it be able to easily edit the code (unless node starts serving it). I think it would be preferable to have a standalone app.

The front-end code can be deployed in a different manner, e.g. it could be provided as a .deb package. I just described how it is implemented in Chrome at the moment and it has been working pretty well for providing zero-conf Android debugging experience across all platforms. Being able to see Node instances as another type of inspectable target in chrome:inspect looks natural to me but this doesn't have to be the only way to debug Node.

yury-s commented Aug 26, 2015

@benjamingr :

I'd much prefer it if it was possible to run the debugger without accessing code served from the cloud live. Node would have no control over which versions are supported and how - nor would it be able to easily edit the code (unless node starts serving it). I think it would be preferable to have a standalone app.

The front-end code can be deployed in a different manner, e.g. it could be provided as a .deb package. I just described how it is implemented in Chrome at the moment and it has been working pretty well for providing zero-conf Android debugging experience across all platforms. Being able to see Node instances as another type of inspectable target in chrome:inspect looks natural to me but this doesn't have to be the only way to debug Node.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

@jkrems :

Would the scope include things like PageAgent.reload to restart a node process from inside the devtools or the NetworkAgent/ConsoleAgent/...?

At the moment it includes Debugger, Runtime, Profiler and HeapProfiler agents which make sense for all v8 embedders. Console could be added to the list later. On the other hand, PageAgent doesn't make much sense for Node so we'd rather keep it in Blink. If we need "reload" functionality, the method could be moved to e.g. to Runtime domain or Node can have its own domain "Node" providing functionality specific to Node.js The front-end can either support this in the core or we can have it as a third-party module. This is definitely not something for v.1 and deserves separate discussion.

yury-s commented Aug 26, 2015

@jkrems :

Would the scope include things like PageAgent.reload to restart a node process from inside the devtools or the NetworkAgent/ConsoleAgent/...?

At the moment it includes Debugger, Runtime, Profiler and HeapProfiler agents which make sense for all v8 embedders. Console could be added to the list later. On the other hand, PageAgent doesn't make much sense for Node so we'd rather keep it in Blink. If we need "reload" functionality, the method could be moved to e.g. to Runtime domain or Node can have its own domain "Node" providing functionality specific to Node.js The front-end can either support this in the core or we can have it as a third-party module. This is definitely not something for v.1 and deserves separate discussion.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

@auchenberg :

As I understand it, the debugger back-end is separate from the core via v8-inspector, and since it would implement the Chrome Remote Debugging Protocol over WebSocket and HTTP, the debugger back-end would be compatible with external front-ends like Chrome DevTools App (based upon Electron)

Correct. Other front-ends should be able to connect using the same transport. Note though that we don't want to commit to backward compatibility of the whole protocol. It would be up to the front-end authors to make sure that their front-end is compatible with given back-end. We only promise to provide compatible version of DevTools front-end.

By having a runtime/protocol version we will be able to match the front-end with the back-end. Eventually this would need to use some kind of feature detection, but that's further out in the future, as I see it.

Note that this version only relates to the subset of public commands in the protocol. We have been reluctant to making more commands public so the protocol version hasn't changed for a while. Majority of the commands in the protocol are non-public and they have been changing quite often. To ensure full compatibility with the protocol discovery page returns exact version (198849) of the front-end that should be used.

yury-s commented Aug 26, 2015

@auchenberg :

As I understand it, the debugger back-end is separate from the core via v8-inspector, and since it would implement the Chrome Remote Debugging Protocol over WebSocket and HTTP, the debugger back-end would be compatible with external front-ends like Chrome DevTools App (based upon Electron)

Correct. Other front-ends should be able to connect using the same transport. Note though that we don't want to commit to backward compatibility of the whole protocol. It would be up to the front-end authors to make sure that their front-end is compatible with given back-end. We only promise to provide compatible version of DevTools front-end.

By having a runtime/protocol version we will be able to match the front-end with the back-end. Eventually this would need to use some kind of feature detection, but that's further out in the future, as I see it.

Note that this version only relates to the subset of public commands in the protocol. We have been reluctant to making more commands public so the protocol version hasn't changed for a while. Majority of the commands in the protocol are non-public and they have been changing quite often. To ensure full compatibility with the protocol discovery page returns exact version (198849) of the front-end that should be used.

@yunong

This comment has been minimized.

Show comment
Hide comment
@yunong

yunong Aug 26, 2015

This looks great. I'd love to be able to get the ability to walk the JS objects on the heap that is currently provided by mdb and v8.so https://www.joyent.com/blog/debugging-enhancements-in-node-0-12

Specifically, to be able to walk an object reference all the way back to the root object would be incredibly helpful in debugging memory leaks.

e.g. given a particular object's address, find references to all other objects that refer to this object, similar to what findjsobjects -r does.

yunong commented Aug 26, 2015

This looks great. I'd love to be able to get the ability to walk the JS objects on the heap that is currently provided by mdb and v8.so https://www.joyent.com/blog/debugging-enhancements-in-node-0-12

Specifically, to be able to walk an object reference all the way back to the root object would be incredibly helpful in debugging memory leaks.

e.g. given a particular object's address, find references to all other objects that refer to this object, similar to what findjsobjects -r does.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 26, 2015

Contributor

Summary points:

  • While the integration API is unstable, that doesn't matter much. What needs a certain amount of stability is the debugger protocol. It seems the debugger/profiler API have stabilized for the most part, but are still prone to breakage. How this will be handled over the course of an LTS needs to be solidified.
  • The protocol requires web sockets. Does this mean node will have to natively support them as well?
  • Discovery still needs to be done on all the injection points the API will need into core code.
Contributor

trevnorris commented Aug 26, 2015

Summary points:

  • While the integration API is unstable, that doesn't matter much. What needs a certain amount of stability is the debugger protocol. It seems the debugger/profiler API have stabilized for the most part, but are still prone to breakage. How this will be handled over the course of an LTS needs to be solidified.
  • The protocol requires web sockets. Does this mean node will have to natively support them as well?
  • Discovery still needs to be done on all the injection points the API will need into core code.
@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Aug 26, 2015

Contributor

Is it possible to expose enough bits to make it transport-agnostic? This would allow core to avoid having to bundle a particular module for this to work.

Contributor

mscdex commented Aug 26, 2015

Is it possible to expose enough bits to make it transport-agnostic? This would allow core to avoid having to bundle a particular module for this to work.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

Is it possible to expose enough bits to make it transport-agnostic?

See second item in the "Open questions" section above and this comment above. There is a clear separation between v8-inspector and the transport provider. In the prototype remote_debugging_server.js requires three methods on node_debugger:

    node_debugger.connectToInspectorBackend(channel);
    node_debugger.dispatchOnInspectorBackend(message);
    node_debugger.disconnectFromInspectorBackend();

And provides single callback method:

   channel.sendMessageToFrontend = function(message) {...}

On top of that there can be a third-party WebSocket server or module providing another transport.

yury-s commented Aug 26, 2015

Is it possible to expose enough bits to make it transport-agnostic?

See second item in the "Open questions" section above and this comment above. There is a clear separation between v8-inspector and the transport provider. In the prototype remote_debugging_server.js requires three methods on node_debugger:

    node_debugger.connectToInspectorBackend(channel);
    node_debugger.dispatchOnInspectorBackend(message);
    node_debugger.disconnectFromInspectorBackend();

And provides single callback method:

   channel.sendMessageToFrontend = function(message) {...}

On top of that there can be a third-party WebSocket server or module providing another transport.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 26, 2015

@trevnorris :

While the integration API is unstable, that doesn't matter much. What needs a certain amount of stability is the debugger protocol. It seems the debugger/profiler API have stabilized for the most part, but are still prone to breakage. How this will be handled over the course of an LTS needs to be solidified.

While the debugger/profiler protocol may have been stable for a while there is still a chance that we'll need to make some breaking changes to it to move the project forward. We tried to keep stable subset of the protocol and it proved to be hard. We don't want to go that route if possible. Why do you think that we need stability of the remote debugging protocol with the proposed solution?

yury-s commented Aug 26, 2015

@trevnorris :

While the integration API is unstable, that doesn't matter much. What needs a certain amount of stability is the debugger protocol. It seems the debugger/profiler API have stabilized for the most part, but are still prone to breakage. How this will be handled over the course of an LTS needs to be solidified.

While the debugger/profiler protocol may have been stable for a while there is still a chance that we'll need to make some breaking changes to it to move the project forward. We tried to keep stable subset of the protocol and it proved to be hard. We don't want to go that route if possible. Why do you think that we need stability of the remote debugging protocol with the proposed solution?

@JacksonTian

This comment has been minimized.

Show comment
Hide comment
@JacksonTian

JacksonTian Aug 27, 2015

Contributor

Hope to see an improved debugger.

Contributor

JacksonTian commented Aug 27, 2015

Hope to see an improved debugger.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Aug 27, 2015

Contributor

@yury-s

While the debugger/profiler protocol may have been stable for a while there is still a chance that we'll need to make some breaking changes to it to move the project forward.

If we still have access to the debugging console that can interpret the incoming JSON, that should be enough. This would actually be preferred. So the UI that developers have been using doesn't change over the lifetime of the release. To solidify what has been mentioned earlier, will we be able to use, and have access to, the older debugging consoles for older APIs?

Contributor

trevnorris commented Aug 27, 2015

@yury-s

While the debugger/profiler protocol may have been stable for a while there is still a chance that we'll need to make some breaking changes to it to move the project forward.

If we still have access to the debugging console that can interpret the incoming JSON, that should be enough. This would actually be preferred. So the UI that developers have been using doesn't change over the lifetime of the release. To solidify what has been mentioned earlier, will we be able to use, and have access to, the older debugging consoles for older APIs?

@mattdesl

This comment has been minimized.

Show comment
Hide comment
@mattdesl

mattdesl Aug 27, 2015

One natural approach to that is to reuse Chrome DevTools and provide its JS debugger, performance and memory profiler functionality to Node.js users.

Another approach worth mentioning is leveraging Electron to launch a DevTools window with node integration. See hihat for an example. It has its own limitations, but doesn't involve remote debugging and provides a couple benefits over node-inspector (e.g. a more complete DevTools UX).

Having better debugging built-in to Node would be amazing, though. 😄 It's one of those things you take for granted when you start to do a lot of frontend development.

One natural approach to that is to reuse Chrome DevTools and provide its JS debugger, performance and memory profiler functionality to Node.js users.

Another approach worth mentioning is leveraging Electron to launch a DevTools window with node integration. See hihat for an example. It has its own limitations, but doesn't involve remote debugging and provides a couple benefits over node-inspector (e.g. a more complete DevTools UX).

Having better debugging built-in to Node would be amazing, though. 😄 It's one of those things you take for granted when you start to do a lot of frontend development.

@yury-s

This comment has been minimized.

Show comment
Hide comment
@yury-s

yury-s Aug 27, 2015

@trevnorris

If we still have access to the debugging console that can interpret the incoming JSON, that should be enough. This would actually be preferred. So the UI that developers have been using doesn't change over the lifetime of the release. To solidify what has been mentioned earlier, will we be able to use, and have access to, the older debugging consoles for older APIs?

This is exactly the what should happen if I understand correctly what you mean. Let's assume that v8 stable branch used in Chrome 44 was created from v8 v.4.4.63 and that Blink used in Chrome 44 was branched from 195420. Let's also assume that DevTools backend implementation in Blink is based on revision 1024 of v8-inspector. As long as Node is compiled with v8-inspector r1024 the users should be able to debug it with r195420 of the front-end. Any Chrome version >= 44 can be used to host the front-end (as I mentioned above the source of the front-end will be served from https://chrome-devtools-frontend.appspot.com/serve_rev/@195420/inspector.html) and will work transparently to the user, the front-end could also be provided as Electron app or something else.

yury-s commented Aug 27, 2015

@trevnorris

If we still have access to the debugging console that can interpret the incoming JSON, that should be enough. This would actually be preferred. So the UI that developers have been using doesn't change over the lifetime of the release. To solidify what has been mentioned earlier, will we be able to use, and have access to, the older debugging consoles for older APIs?

This is exactly the what should happen if I understand correctly what you mean. Let's assume that v8 stable branch used in Chrome 44 was created from v8 v.4.4.63 and that Blink used in Chrome 44 was branched from 195420. Let's also assume that DevTools backend implementation in Blink is based on revision 1024 of v8-inspector. As long as Node is compiled with v8-inspector r1024 the users should be able to debug it with r195420 of the front-end. Any Chrome version >= 44 can be used to host the front-end (as I mentioned above the source of the front-end will be served from https://chrome-devtools-frontend.appspot.com/serve_rev/@195420/inspector.html) and will work transparently to the user, the front-end could also be provided as Electron app or something else.

@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Mar 2, 2016

Member

@jkrems I suppose that everything I noted above is still valid with the websocket implementation being in ./deps/.

Member

ChALkeR commented Mar 2, 2016

@jkrems I suppose that everything I noted above is still valid with the websocket implementation being in ./deps/.

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Mar 2, 2016

Contributor

@ChALkeR Sorry, I completely mis-parsed your first paragraph. Thought you were talking about the fact that it currently does require an explicit npm install when setting up (pavelfeldman@86939cb#diff-04c6e90faac2675aa89e2176d2eec7d8R21). But now re-reading your comment it sounds like you would prefer it if node would just ship with the hooks for the protocol and leaving it up to an external (possible npm-) module to actually hook it up to a websocket?

Contributor

jkrems commented Mar 2, 2016

@ChALkeR Sorry, I completely mis-parsed your first paragraph. Thought you were talking about the fact that it currently does require an explicit npm install when setting up (pavelfeldman@86939cb#diff-04c6e90faac2675aa89e2176d2eec7d8R21). But now re-reading your comment it sounds like you would prefer it if node would just ship with the hooks for the protocol and leaving it up to an external (possible npm-) module to actually hook it up to a websocket?

@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Mar 2, 2016

Member

@jkrems Yes, that's what I meant.

Member

ChALkeR commented Mar 2, 2016

@jkrems Yes, that's what I meant.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Mar 2, 2016

Contributor

@ChALkeR: The problem with having part of the functionality being provided by user-space module is that it breaks the out-of-the-box debug experience. In many cases, at the time the user realizes that need to debug something, it may already be too late to get an npm module installed.

That would also potentially break the schedule and could even force us to introduce some backwards incompatible changes.

I am not sure I follow the point about backwards incompatible changes – since it is not going to be externally exposed. We (node-core) will need to address security vulnerabilities in upstream ws (or alternative websockets implementation) and dependent packages. In my opinion, the security impact would be higher if core functionality (remote debug server) were to be dependent on externally provided modules that node-core cannot patch by providing a security update.

I think these are excellent discussions. I suspect that this thread will get unwieldy fast if we were to have these discussions here. Apropos #2546 (comment), I propose that we create a branch to work on the v8-inspector integration and use individual PRs to discuss individual design points (websockets, event loop integration, ergonomics, etc.). If there are no objections, I'll proceed with that route.

Contributor

ofrobots commented Mar 2, 2016

@ChALkeR: The problem with having part of the functionality being provided by user-space module is that it breaks the out-of-the-box debug experience. In many cases, at the time the user realizes that need to debug something, it may already be too late to get an npm module installed.

That would also potentially break the schedule and could even force us to introduce some backwards incompatible changes.

I am not sure I follow the point about backwards incompatible changes – since it is not going to be externally exposed. We (node-core) will need to address security vulnerabilities in upstream ws (or alternative websockets implementation) and dependent packages. In my opinion, the security impact would be higher if core functionality (remote debug server) were to be dependent on externally provided modules that node-core cannot patch by providing a security update.

I think these are excellent discussions. I suspect that this thread will get unwieldy fast if we were to have these discussions here. Apropos #2546 (comment), I propose that we create a branch to work on the v8-inspector integration and use individual PRs to discuss individual design points (websockets, event loop integration, ergonomics, etc.). If there are no objections, I'll proceed with that route.

@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Mar 2, 2016

Member

@ofrobots

I am not sure I follow the point about backwards incompatible changes – since it is not going to be externally exposed.

The debugger is going to be exposed, and it could lose compatibility with older browser versions at some point. Or am I misunderstanding something?

In my opinion, the security impact would be higher if core functionality (remote debug server) were to be dependent on externally provided modules that node-core cannot patch by providing a security update.

I meant — package it separately (perhaps installable with npm install), but keep in the nodejs org. Like nan, for example.

Btw, that means that we could force people to upgrade that tool if we really need them to — Node.js could check the version of the debugger tool being used and refuse to work with it if it's too old.

Member

ChALkeR commented Mar 2, 2016

@ofrobots

I am not sure I follow the point about backwards incompatible changes – since it is not going to be externally exposed.

The debugger is going to be exposed, and it could lose compatibility with older browser versions at some point. Or am I misunderstanding something?

In my opinion, the security impact would be higher if core functionality (remote debug server) were to be dependent on externally provided modules that node-core cannot patch by providing a security update.

I meant — package it separately (perhaps installable with npm install), but keep in the nodejs org. Like nan, for example.

Btw, that means that we could force people to upgrade that tool if we really need them to — Node.js could check the version of the debugger tool being used and refuse to work with it if it's too old.

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Mar 2, 2016

Contributor

@ChALkeR Given that this interface is - afaik - meant as a replacement for the current JSON/TCP API, putting the interface into something external to node would mean that it would no longer be possible for something like an IDE to run a node program in debug mode without having to "patch in" that library. That doesn't sound like a great developer experience imo.

Contributor

jkrems commented Mar 2, 2016

@ChALkeR Given that this interface is - afaik - meant as a replacement for the current JSON/TCP API, putting the interface into something external to node would mean that it would no longer be possible for something like an IDE to run a node program in debug mode without having to "patch in" that library. That doesn't sound like a great developer experience imo.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Mar 2, 2016

Contributor

Only skimmed over the recent comments, so excuse any duplicates.

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

Contributor

trevnorris commented Mar 2, 2016

Only skimmed over the recent comments, so excuse any duplicates.

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Mar 3, 2016

Contributor

@trevnorris

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

Indeed. That's another option we are investigating. More specifically, we're looking at what would be involved in pulling out the websockets implementation devtools is using in blink. We haven't looked at it enough to know in detail whether we can extract it and plug it into Node. Note however, that we are more interested in getting devtools working with Node than we are in designing a websockets implementation for core. We're trying to find the path of least resistance here.

@ChALkeR

Btw, that means that we could force people to upgrade that tool if we really need them to — Node.js could check the version of the debugger tool being used and refuse to work with it if it's too old.

I think this stance is hostile to our users. If we think debug functionality is important to core, then we will need to own up to the security implications of supporting such functionality. There are cases where the user trying to debug may not be able to install a module from npm (e.g. shrink wrapped deps scenarios, etc.) Having said that, we are also looking at alternative (non-js) implementations of websockets (collaboration from the community on this is welcome). It is possible that we may be able to avoid this debate.

Contributor

ofrobots commented Mar 3, 2016

@trevnorris

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

Indeed. That's another option we are investigating. More specifically, we're looking at what would be involved in pulling out the websockets implementation devtools is using in blink. We haven't looked at it enough to know in detail whether we can extract it and plug it into Node. Note however, that we are more interested in getting devtools working with Node than we are in designing a websockets implementation for core. We're trying to find the path of least resistance here.

@ChALkeR

Btw, that means that we could force people to upgrade that tool if we really need them to — Node.js could check the version of the debugger tool being used and refuse to work with it if it's too old.

I think this stance is hostile to our users. If we think debug functionality is important to core, then we will need to own up to the security implications of supporting such functionality. There are cases where the user trying to debug may not be able to install a module from npm (e.g. shrink wrapped deps scenarios, etc.) Having said that, we are also looking at alternative (non-js) implementations of websockets (collaboration from the community on this is welcome). It is possible that we may be able to avoid this debate.

@jkrems

This comment has been minimized.

Show comment
Hide comment
@jkrems

jkrems Mar 3, 2016

Contributor

I'd volunteer to port the needed parts of ws to C++ but I'm not sure if that would be a net positive long-term. Those parts would need some level of maintenance and I'm assuming that bigger chunks of C++ will always be scarier to contributors than JS. Is the current solution (additional V8 context for the debugger thread) causing known issues? There's some ugly parts (e.g. src/node.js having to do some branching if it's running as a debugger thread) but otherwise it seems - relatively - fine to me.

Maybe (random thought) the code for the devtools bindings could even live in the exact same place the current v8 protocol code lives. This might help make the branching between the two interfaces less confusing.

Contributor

jkrems commented Mar 3, 2016

I'd volunteer to port the needed parts of ws to C++ but I'm not sure if that would be a net positive long-term. Those parts would need some level of maintenance and I'm assuming that bigger chunks of C++ will always be scarier to contributors than JS. Is the current solution (additional V8 context for the debugger thread) causing known issues? There's some ugly parts (e.g. src/node.js having to do some branching if it's running as a debugger thread) but otherwise it seems - relatively - fine to me.

Maybe (random thought) the code for the devtools bindings could even live in the exact same place the current v8 protocol code lives. This might help make the branching between the two interfaces less confusing.

@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Mar 4, 2016

Member

@trevnorris

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

Adding in a brand new c++ implementation of WebSockets gives me an even more uneasy feeling.

I might be missing something again, but why creating an IPC interface on the main thread and hooking to it and passing over WebSocket by a standalone process (that could reuse ws) is not an option?

Member

ChALkeR commented Mar 4, 2016

@trevnorris

The debugger will require the websocket server to run off the main thread, IIRC. Along those lines, it would be more beneficial if that implementation was done w/o requiring a v8 stack. Which rules out using a third-party module.

Adding in a brand new c++ implementation of WebSockets gives me an even more uneasy feeling.

I might be missing something again, but why creating an IPC interface on the main thread and hooking to it and passing over WebSocket by a standalone process (that could reuse ws) is not an option?

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Mar 4, 2016

There is node-lws which I think is fully C++

There is node-lws which I think is fully C++

@joshgav

This comment has been minimized.

Show comment
Hide comment
@joshgav

joshgav Mar 9, 2016

Member

@ofrobots (emphasis added)

To this end we have been working on extracting the DevTools backend from blink, extricate all its dependencies on Blink, and get it integrated into V8 instead.

Once extricated from Blink, would it make more sense to permanently keep v8-inspector as an independent component from v8? That would give us (Node) more flexibility as you already noted, and better facilitate external contributions of additional functionality to v8-inspector.

Member

joshgav commented Mar 9, 2016

@ofrobots (emphasis added)

To this end we have been working on extracting the DevTools backend from blink, extricate all its dependencies on Blink, and get it integrated into V8 instead.

Once extricated from Blink, would it make more sense to permanently keep v8-inspector as an independent component from v8? That would give us (Node) more flexibility as you already noted, and better facilitate external contributions of additional functionality to v8-inspector.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Mar 9, 2016

Contributor

@joshgav The end goal is to get v8-inspector integrated directly into V8 as the fully featured debug API for V8. It is very closely tied to the internals of V8, and keeping them separate is going to be more work for embedders and the developers alike. We would love to see contributions from the community – I think contributing would be a lot easier once this is in V8, but if there is friction please do let us know. /cc @repenaxa.

Contributor

ofrobots commented Mar 9, 2016

@joshgav The end goal is to get v8-inspector integrated directly into V8 as the fully featured debug API for V8. It is very closely tied to the internals of V8, and keeping them separate is going to be more work for embedders and the developers alike. We would love to see contributions from the community – I think contributing would be a lot easier once this is in V8, but if there is friction please do let us know. /cc @repenaxa.

@pavelfeldman

This comment has been minimized.

Show comment
Hide comment
@pavelfeldman

pavelfeldman Mar 9, 2016

Contributor

Although v8-inspector will live outside of Blink, it will still be used there. As well as in other non-Chrome and non-Node V8 embedders. We were thinking about making it a third party dependency, but eventually decided against it:

  • it creates a new step in the dependency roll: Blink -> v8-inspector -> v8 that we can not afford
  • it limits our ability to iterate due to two-sided patches and the v8.h surface limitation
  • v8-inspector exposes the debugging APIs (wired and strongly-typed) that needs to be versioned and introducing an dependent component with a separate API versioning sounded like too much overhead.

Having said that, we plan to move v8-inspector into v8 along with its contributors! So it would start with the Chrome DevTools and some V8 people and will grow from there. As @ofrobots mentioned, we can work on minimizing the associated friction.

Contributor

pavelfeldman commented Mar 9, 2016

Although v8-inspector will live outside of Blink, it will still be used there. As well as in other non-Chrome and non-Node V8 embedders. We were thinking about making it a third party dependency, but eventually decided against it:

  • it creates a new step in the dependency roll: Blink -> v8-inspector -> v8 that we can not afford
  • it limits our ability to iterate due to two-sided patches and the v8.h surface limitation
  • v8-inspector exposes the debugging APIs (wired and strongly-typed) that needs to be versioned and introducing an dependent component with a separate API versioning sounded like too much overhead.

Having said that, we plan to move v8-inspector into v8 along with its contributors! So it would start with the Chrome DevTools and some V8 people and will grow from there. As @ofrobots mentioned, we can work on minimizing the associated friction.

@cjihrig cjihrig referenced this issue May 5, 2016

Merged

src,lib: minor --debug-brk cleanup #6599

3 of 3 tasks complete

@nsipplswezey nsipplswezey referenced this issue in keithwhor/nodal May 8, 2016

Closed

Integration with node-inspector #225

@paulirish paulirish referenced this issue in tapjs/signal-exit May 13, 2016

Closed

Don't listen to SIGPROF #21

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots May 16, 2016

Contributor

I just opened a PR with initial v8_inpector support: #6792.

Contributor

ofrobots commented May 16, 2016

I just opened a PR with initial v8_inpector support: #6792.

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jun 2, 2016

Contributor

Can this be closed now?

Contributor

trevnorris commented Jun 2, 2016

Can this be closed now?

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Jun 2, 2016

Contributor

I think so. Please reopen if I'm wrong.

Contributor

cjihrig commented Jun 2, 2016

I think so. Please reopen if I'm wrong.

@xaxxon

This comment has been minimized.

Show comment
Hide comment
@xaxxon

xaxxon Oct 5, 2016

What is the current status on the effort to integrate in with vanilla v8? I'm currently building this functionality and have it minimally functional but would rather not, but I don't know how to find out about the progress being made.

Thank you.

xaxxon commented Oct 5, 2016

What is the current status on the effort to integrate in with vanilla v8? I'm currently building this functionality and have it minimally functional but would rather not, but I don't know how to find out about the progress being made.

Thank you.

@bmeck

This comment has been minimized.

Show comment
Hide comment
@bmeck

bmeck Oct 5, 2016

Member

@xaxxon use node --inspect on v6+, should work fairly well

Member

bmeck commented Oct 5, 2016

@xaxxon use node --inspect on v6+, should work fairly well

@xaxxon

This comment has been minimized.

Show comment
Hide comment
@xaxxon

xaxxon Oct 5, 2016

I'm not using node, though.

On Wed, Oct 5, 2016 at 8:23 AM, Bradley Meck notifications@github.com
wrote:

@xaxxon https://github.com/xaxxon use node --inspect on v6+, should
work fairly well


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIycuUi5Tj8B7sVus9suliVTUI_stEeks5qw8DWgaJpZM4FyAmT
.

xaxxon commented Oct 5, 2016

I'm not using node, though.

On Wed, Oct 5, 2016 at 8:23 AM, Bradley Meck notifications@github.com
wrote:

@xaxxon https://github.com/xaxxon use node --inspect on v6+, should
work fairly well


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIycuUi5Tj8B7sVus9suliVTUI_stEeks5qw8DWgaJpZM4FyAmT
.

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Oct 5, 2016

Contributor

You might want to check the V8 issue tracker then.

Contributor

cjihrig commented Oct 5, 2016

You might want to check the V8 issue tracker then.

@eugeneo

This comment has been minimized.

Show comment
Hide comment
@eugeneo

eugeneo Oct 5, 2016

Contributor

The code is in the V8 now, e.g. -
https://github.com/v8/v8/tree/ba41697cbd72ea7dcdd89e6dbe9090ecb156ce6c/src/inspector

On Wed, Oct 5, 2016 at 8:24 AM Colin Ihrig notifications@github.com wrote:

You might want to check the V8 issue tracker then.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARkrVMxf-2hCea0SHccmwmrYQR7_m7Wks5qw8E8gaJpZM4FyAmT
.

Contributor

eugeneo commented Oct 5, 2016

The code is in the V8 now, e.g. -
https://github.com/v8/v8/tree/ba41697cbd72ea7dcdd89e6dbe9090ecb156ce6c/src/inspector

On Wed, Oct 5, 2016 at 8:24 AM Colin Ihrig notifications@github.com wrote:

You might want to check the V8 issue tracker then.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARkrVMxf-2hCea0SHccmwmrYQR7_m7Wks5qw8E8gaJpZM4FyAmT
.

@xaxxon

This comment has been minimized.

Show comment
Hide comment
@xaxxon

xaxxon Oct 5, 2016

thank you.

On Wed, Oct 5, 2016 at 9:24 AM, Eugene Ostroukhov notifications@github.com
wrote:

The code is in the V8 now, e.g. -
https://github.com/v8/v8/tree/ba41697cbd72ea7dcdd89e6dbe9090
ecb156ce6c/src/inspector

On Wed, Oct 5, 2016 at 8:24 AM Colin Ihrig notifications@github.com
wrote:

You might want to check the V8 issue tracker then.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AARkrVMxf-
2hCea0SHccmwmrYQR7_m7Wks5qw8E8gaJpZM4FyAmT>

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIyckAW2RICpAYxAYi6zBOjV2PykixBks5qw88-gaJpZM4FyAmT
.

xaxxon commented Oct 5, 2016

thank you.

On Wed, Oct 5, 2016 at 9:24 AM, Eugene Ostroukhov notifications@github.com
wrote:

The code is in the V8 now, e.g. -
https://github.com/v8/v8/tree/ba41697cbd72ea7dcdd89e6dbe9090
ecb156ce6c/src/inspector

On Wed, Oct 5, 2016 at 8:24 AM Colin Ihrig notifications@github.com
wrote:

You might want to check the V8 issue tracker then.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AARkrVMxf-
2hCea0SHccmwmrYQR7_m7Wks5qw8E8gaJpZM4FyAmT>

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIyckAW2RICpAYxAYi6zBOjV2PykixBks5qw88-gaJpZM4FyAmT
.

@msaspence

This comment has been minimized.

Show comment
Hide comment
@msaspence

msaspence Nov 2, 2016

I wonder if it is currently or would be possible to access this url programatically from the Node process?

I wonder if it is currently or would be possible to access this url programatically from the Node process?

@eugeneo

This comment has been minimized.

Show comment
Hide comment
@eugeneo

eugeneo Nov 2, 2016

Contributor

No, not yet. We can expose it if it is really needed.

Contributor

eugeneo commented Nov 2, 2016

No, not yet. We can expose it if it is really needed.

@msaspence

This comment has been minimized.

Show comment
Hide comment
@msaspence

msaspence Nov 2, 2016

I'm just think it would be nice to be able to expose it so in the process can open the tab for you automatically if you so wish. However It seems that you can actually determine the URL yourself if you know the port, which you can specify with --inspect=1234

msaspence commented Nov 2, 2016

I'm just think it would be nice to be able to expose it so in the process can open the tab for you automatically if you so wish. However It seems that you can actually determine the URL yourself if you know the port, which you can specify with --inspect=1234

@eugeneo

This comment has been minimized.

Show comment
Hide comment
@eugeneo

eugeneo Nov 2, 2016

Contributor

UUID is not exposed.

On Wed, Nov 2, 2016 at 9:55 AM Matthew Spence notifications@github.com
wrote:

I'm just think it would be nice to be able to expose it so in the process
can open the tab for you automatically if you so wish. However It seems
that you can actually determine the URL yourself if you know the port,
which you can specify with --inspect=1234


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARkrVmlK-gwGRcNbq4PZSlaTl8O2cSEks5q6MCRgaJpZM4FyAmT
.

Contributor

eugeneo commented Nov 2, 2016

UUID is not exposed.

On Wed, Nov 2, 2016 at 9:55 AM Matthew Spence notifications@github.com
wrote:

I'm just think it would be nice to be able to expose it so in the process
can open the tab for you automatically if you so wish. However It seems
that you can actually determine the URL yourself if you know the port,
which you can specify with --inspect=1234


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2546 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARkrVmlK-gwGRcNbq4PZSlaTl8O2cSEks5q6MCRgaJpZM4FyAmT
.

@msaspence

This comment has been minimized.

Show comment
Hide comment
@msaspence

msaspence Nov 2, 2016

With chrome-cli installed (open doesn't like the chrome-devtools protocol) I have the following proof of concept working on node 6.9.1

const { exec } = require('child_process');
  exec('chrome-cli list links', (_error, stdout) => {
    const url = `chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=localhost:${process.env.npm_package_config_debugPort || 9221}/node`;
    const match = stdout.match(new RegExp(`\\[(\\d+)\\] chrome-devtools://devtools/bundled/inspector.html\\?experiments=true&v8only=true&ws=localhost:${process.env.npm_package_config_debugPort || 9221}/node`));
    const tabId = match ? ` -t ${match[1]}` : '';
    exec(`chrome-cli open "${url}"${tabId}`);
  });

Where $npm_package_config_debugPort is provided to the node --inspect flag.

msaspence commented Nov 2, 2016

With chrome-cli installed (open doesn't like the chrome-devtools protocol) I have the following proof of concept working on node 6.9.1

const { exec } = require('child_process');
  exec('chrome-cli list links', (_error, stdout) => {
    const url = `chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=localhost:${process.env.npm_package_config_debugPort || 9221}/node`;
    const match = stdout.match(new RegExp(`\\[(\\d+)\\] chrome-devtools://devtools/bundled/inspector.html\\?experiments=true&v8only=true&ws=localhost:${process.env.npm_package_config_debugPort || 9221}/node`));
    const tabId = match ? ` -t ${match[1]}` : '';
    exec(`chrome-cli open "${url}"${tabId}`);
  });

Where $npm_package_config_debugPort is provided to the node --inspect flag.

@june07

This comment has been minimized.

Show comment
Hide comment
@june07

june07 Nov 16, 2016

I was having the same issue a few days ago and wrote a Chrome extension to solve it. Would love any feedback.

http://june07.com/nim

Direct Chrome Web Store link: https://chrome.google.com/webstore/detail/nim-node-inspector-monito/gnhhdgbaldcilmgcpfddgdbkhjohddkj

june07 commented Nov 16, 2016

I was having the same issue a few days ago and wrote a Chrome extension to solve it. Would love any feedback.

http://june07.com/nim

Direct Chrome Web Store link: https://chrome.google.com/webstore/detail/nim-node-inspector-monito/gnhhdgbaldcilmgcpfddgdbkhjohddkj

@billfeller billfeller referenced this issue in billfeller/billfeller.github.io Nov 25, 2016

Open

Debugging Node.js #155

@oncletom oncletom referenced this issue in oncletom/nodebook Jan 20, 2017

Closed

Mentionner node --inspect #65

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment