Ps: If this directory is not there, then open the Debug view inside Visual Studio Code (Ctrl + Shift + D) so the option to create it will be presented to you.
After saving this file with the Mocha options, when you go to the Debug view, you’ll see “Run mocha” as one of the options for running the debugger. That’s our newly created launch config.
When you click on the play button it will start running the tests inside the bin/test directory, if you followed the configuration I created on my previous post about testing with Mocha. If there’s no bin directory yet with the transpiled TypeScript, then you’ll have to run gulp before to create it and run the gulp tasks.
Before running the debugger, you can also set a breakpoint in the code by clicking on the line you want, before the line number. When you run the tests and at least one of the tests access this part of the code, the debugger will stop there and show the current state of the variable(s) in the line where you put the breakpoint. It shows all the properties of a json object, for example, if you hover it with the mouse pointer.
In the bottom left corner you can see the breakpoints that you configured.
Here only two of the tests will be executed.
This way you are able to debug only the parts you want and get to the breakpoints you configured faster.
As you can see in the top, we have the debugger controls. Play (F5) will go to the next breakpoint, step into (F11) will go to the next line, and step out (Shift + F11) will exit a method or loop and go to the next instruction if you need.
If you press Ctrl + Shift + B now and you have no tasks configured, Visual Studio Code will run some detections and give you suggestions. For a TypeScript project it will show you “tsc: build - tsconfig.json”, which will be a task based on the tsconfig.json file you have on your project. Choose that option so it starts running in the terminal and watching for changes.
Here I renamed the method getOne to getOne1 in order to test it and it transpiled the tasks.ts file automatically to bin/tasks.js with the new method name, but it showed an error, since getOne is being called inside the tasks.ts route and it doesn’t exist anymore.
The first icon in the bottom left corner, before the circled X, will be always moving while a task is active.
In order to stop the task, press Ctrl + C while the focus is on the terminal.
This puts an end to the need of console.log commands everywhere on your source code, as this debug feature on Visual Studio Code works pretty well.
Is there any other task or tip you have for Visual Studio Code you know and like to use? Let me know in the comments!
Configuring Visual Studio Code for debugging Node.js and transpiling TypeScript was published on September 09, 2017 .