{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/node/issues/2546","labels_url":"https://api.github.com/repos/nodejs/node/issues/2546/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/node/issues/2546/comments","events_url":"https://api.github.com/repos/nodejs/node/issues/2546/events","html_url":"https://github.com/nodejs/node/issues/2546","id":103096346,"number":2546,"title":"Inspecting Node.js with Chrome DevTools","user":{"login":"yury-s","id":9798949,"avatar_url":"https://avatars.githubusercontent.com/u/9798949?v=3","gravatar_id":"","url":"https://api.github.com/users/yury-s","html_url":"https://github.com/yury-s","followers_url":"https://api.github.com/users/yury-s/followers","following_url":"https://api.github.com/users/yury-s/following{/other_user}","gists_url":"https://api.github.com/users/yury-s/gists{/gist_id}","starred_url":"https://api.github.com/users/yury-s/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yury-s/subscriptions","organizations_url":"https://api.github.com/users/yury-s/orgs","repos_url":"https://api.github.com/users/yury-s/repos","events_url":"https://api.github.com/users/yury-s/events{/privacy}","received_events_url":"https://api.github.com/users/yury-s/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/nodejs/node/labels/debugger","name":"debugger","color":"bfd4f2"},{"url":"https://api.github.com/repos/nodejs/node/labels/v8","name":"v8","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-08-25T19:16:53Z","updated_at":"2015-08-26T06:26:22Z","closed_at":null,"body":"###  Objective\r\n\r\nWe’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.\r\n\r\n### Internal design\r\n\r\nDevTools 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.\r\n\r\n### Proof of concept\r\n\r\nI’ve created a prototype demonstrating this approach:\r\n\r\nhttps://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.\r\nhttps://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.\r\n\r\nLocal Node debugging scenario with custom ports would look like this:\r\n 1.  Start Node with --remote-debugging-port=9222 command-line flag\r\n 2.  Start Chrome with --remote-debugging-targets=localhost:9222 command-line flag\r\n 3.  Navigate Chrome to chrome:inspect to see list of inspectable Node.js targets\r\n\r\n### Longer term\r\n\r\nLong-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.\r\n\r\n### Open questions\r\n\r\nBefore 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**?\r\n\r\n* This will require compiling Node with the v8-inspector library and providing Node.js-specific implementation of interfaces required by the debugger.\r\n* 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.\r\n* 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).\r\n* 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\r\n* 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.\r\n"},"comment":{"url":"https://api.github.com/repos/nodejs/node/issues/comments/134855396","html_url":"https://github.com/nodejs/node/issues/2546#issuecomment-134855396","issue_url":"https://api.github.com/repos/nodejs/node/issues/2546","id":134855396,"user":{"login":"benjamingr","id":1315533,"avatar_url":"https://avatars.githubusercontent.com/u/1315533?v=3","gravatar_id":"","url":"https://api.github.com/users/benjamingr","html_url":"https://github.com/benjamingr","followers_url":"https://api.github.com/users/benjamingr/followers","following_url":"https://api.github.com/users/benjamingr/following{/other_user}","gists_url":"https://api.github.com/users/benjamingr/gists{/gist_id}","starred_url":"https://api.github.com/users/benjamingr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjamingr/subscriptions","organizations_url":"https://api.github.com/users/benjamingr/orgs","repos_url":"https://api.github.com/users/benjamingr/repos","events_url":"https://api.github.com/users/benjamingr/events{/privacy}","received_events_url":"https://api.github.com/users/benjamingr/received_events","type":"User","site_admin":false},"created_at":"2015-08-26T06:26:22Z","updated_at":"2015-08-26T06:26:22Z","body":"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.\r\n\r\nI 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).\r\n\r\nHuge +1 for the idea by the way. \r\n\r\n\r\n"}}