The last three months were great for Node Inspector. We have received a number of pull requests from the community, and the list of authors has grown by 50% to 28 people. Thank you!
node-debug replaces slc debug
Do you remember the blog post announcing the first Blink-based version of Node Inspector? It mentioned a handy tool that can set up your debugging session in one command: “slc debug”. We have decided to move the implementation of “slc debug” to Node Inspector and thus make it available to all users (see the pull reqest #305). This move will hopefully improve the unfortunate situation where there are at least three competing modules:
…with each one having it’s own advantages and shortcomings.
First of all, don’t forget to install the latest Node Inspector (v0.7.0 or later):
$ npm install -g node-inspector
Now you can start debugging your app.js script by running
$ node-debug app.js
This is what happens behind the scenes:
- Node Inspector is launched in background
- Your script is started via node –debug-brk app.js
- The Node Inspector page is loaded in your default browser
Please note that node-inspector works in Chrome and Opera only. You have to re-open the inspector page in one of those browsers if another browser is your default web browser (e.g. Safari or Internet Explorer).
Now, let’s take a look at what’s new in this release…
Faster start up
To enable setting breakpoints in files not yet loaded, Node Inspector has to crawl your file system and preload the UI with all source files. The initial implementation has several shortcomings, but v0.7 fixes most of them.
Predicting which files an application will load is not easy, especially if a project doesn’t follow best practices. Consider the following example:
C:\> node-debug self-contained-script.js
- *.js (not recursively)
Node Inspector searches for files in two places: application files in the directory of the main script file
(process.argv) and files in the current working directory
(process.cwd()). These two locations are the same unless you are debugging unit-tests (node-debug _mocha). Node Inspector now performs only one search when the locations are the same, which cuts startup time in half.
Ignore EACCESS errors when listing sources
In the rare case when Node Inspector does not have permissions to list a directory, it skips it and prints the error to the console.
If the startup time is still slow, there is a new option to disable the file system search. The trade-off is that you won’t be able to set breakpoints in files not yet loaded.
$ node-debug --no-preload app.js
$ node-inspector --no-preload
Kudos to Dick Hardt for contributing this feature.
Parsing of source map URLs
Every time the Node runtime loads a new script, Node Inspector has to parse the source and look for a special comment containing reference to a source map file. (Source maps enable you to step through CoffeeScript code.) When Node Inspector connects to a Node process, it asks for a list of files already loaded and then processes these files as if they were newly loaded. The processing includes another request to get a source code of the file. You can avoid all these extra requests by asking Node to include source code in the “list scripts” response and that’s exactly what Node Inspector does now.
Better visualization of values
The V8 Debugger Protocol used by Node and the Remote Debugging Protocol used by the DevTools front-end have different data formats for describing values.
Previously, Node Inspector’s conversion implementation did not work correctly for certain types, but the new version fixes all known bugs.
Previously, Node Inspector displayed Date properties as empty objects:
Now it displays them as a full string:
Values of type “Error” can be introspected now, i.e. you can expand the item and view property values.
The debugger protocol truncates all values to 80 characters by default. Previously, Node Inspector displayed long strings like this:
Peter Flannery contributed a patch that increases the limit to 10,000 characters, which should be enough for everybody. Because, frankly, if you need to inspect strings longer than 10,000 characters, then you are doing something wrong.
Run behind a reverse proxy
Pritam Baral has an interesting setup: he is running the Node Inspector behind a reverse proxy Nginx, mounted at a subpath. He discovered a problem with the way Node Inspector used socket.io: both the client script and websocket address were pointed to an absolute path (/socket.io/socket.io.js and /). As of v0.7, these URLs are relative to the main page.
Use WebSockets instead of socket.io
The original Chrome Developer Tools use plain websockets to talk to the server. Node Inspector switched to socket.io many years ago, which has recently turned out to be problematic. A few users have reported problems caused by HTTP proxies like Fiddler (issue #294) or antivirus scanners (issue #274). Additionally, if Node Inspector were using plain websockets, it would be possible to use any RemoteDebug client to debug Node applications, at least in theory.
Kenneth Auchenberg, the author of RemoteDebug initiative, was kind enough to submit a patch. Good bye, socket.io; hello RemoteDebug!
Auto reload on restart
A StackOverflow user asked how to automatically reload the Node Inspector page when the debugged process was restarted (link). One of the answers described a solution that was easy to implement: When the debugged process cannot be reached, wait few hundreds of milliseconds and reload the page. Kudos go to ChrisWren. There are further improvements being considered: watch 3y3’s pull request #289.
Fix loading of source maps
There was a race condition at session startup that could prevent loading of source maps for some of the scripts (#271). The problem is fixed and Node Inspector should always load all your source maps.
Ready to start monitoring event loops, manage Node clusters and chase down memory leaks? We’ve made it easy to get started with StrongOps either locally or on your favorite cloud, with a simple npm install.
- What’s in the upcoming Node v0.12 release? Big performance optimizations, read Ben Noordhuis’ blog to learn more.
- Watch Bert Belder’s comprehensive video presentation on all the new upcoming features in v0.12
- Ready to develop APIs in Node.js and get them connected to your data? We’ve made it easy to get started either locally or on your favorite cloud, with a simple npm install.