This post is part of a series of pieces on Node.js Development for .NET Developers. The other posts in this series can be found here: Node.js Development for .NET Developers
In my previous post I talked about how you can debug Node.js applications regardless of the tool & platform you are using. These days I’m primarily using Visual Studio Code (aka VSCODE) as my primary editor of choice. VSCode has some additional capabilities that make debugging Node.js applications a little easier.
VSCode enables debugging when working with Node.js applications or ASP.NET 5 applications. The VSCode site has a great page explaining all the debugging capabilities that it has to offer… instead of repeating what they say, I’ll just point you there.
In addition, there’s a very good walk-through on getting Node.js debugging configured with VSCode… check the Runtime: Node.js page for more details on that. For that one, just create the Express site using the generator, then add the two lines of JavaScript to write the contents of a variable to the console. Skip the rest of the document and jump down to the section on Debugging your Node Application as it explains exactly how you want to set it up.
I did run into one issue that was entirely my fault, but it wasn’t obvious at first. Make sure that you have the application open as the root folder within VSCode. When you run the generator, it creates a folder myExpressApp. Make sure you open that folder as the root folder within VSCode and not a parent folder like I did. Otherwise the launcher configuration won’t find the correct path.
Instead, of walking you through it, let me just explain how this works. VSCode creates a file called launch.json. This contains one or more configuration. Each configuration tells VSCode what to do. In fact VSCode can generate a launch configuration file for you based on the current project. When you follow the instructions on the afore mentioned link, it creates two configurations. The first one, Launch ./bin/www, will start the site using Node.js in debug mode and attach to the process. The second one, Attach, attaches VSCode to a currently running Node.js debug process.
From the Debug panel in VSCode, you can see all the stuff you’d expect such as variables, watches, call stacks, breakpoints, etc… it’s all pretty slick and very usable.
I’m a big fan of VSCode… I love how simple and focused it is on being an editor. It will be very cool when they ship their plugin system which they are still working on. I just hope they push back on all the users who are asking for dialogs, wizards, designers and stuff like that which will make it more Visual Studio like. Those are IDE things… keep it focused as an editor.
There are two bits of feedback I had though… if you agree, throw a few votes behind them!
- Allow using iTerm2 instead of Terminal.app for debugging - YES YES YES!!!
- Rename “.settings” to “.vscode”, move “typings” in there - except I don’t agree with the “move typings in there” part. All VSCode specific stuff should go in the .settings folder (hopefully renamed to .vscode), but typings is a TypeScript thing and should not be put anywhere… let me control that just like the tsd.json lets you.