This is one of a few posts in a series of pieces on Node.js Development for .NET Developers. Here are the other posts in this series:
- Node.js Development for .NET Developers: Overview
- Node.js Development for .NET Developers: Tools
- Node.js Development for .NET Developers: Developing & Debugging Workflow
- Node.js Development for .NET Developers: Developing & Debugging Workflow - with Visual Studio Code (this post)
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.
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 instructinos 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, ataches 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 bigs 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
.settingsfolder (hopfully renamed to
.vscode), but typings is a TypeScript thing and should not be put anywhere… let me control that just like the