This article covers using the to debug both JavaScript and applications using , and . Node Inspector TypeScript Node.js Chrome DevTools Visual Studio Code WebStorm As described in the , Node.js 6.3 introduced the ( or ) that make to listen via WebSockets for diagnostic commands as defined by the . This protocol has replaced the (Now known as Legacy Protocol), which became obsolete on Node 7.7. Node.js debugging guide āinspectā and āinspect-brkā CLI arguments node --inspect [file] node --inspect-brk[file] node Chrome Debugging Protocol V8 Debugging Protocol Additionally, the meant to preload modules ( ), but most importantly, for debugging purposes, and make Node able to compile and generate source-maps for other languages like TypeScript. For debugging TypeScript weāll use . Itās important to remember that in your , that can be generated by running , you should have , which is the default value. Node CLI also provides a ārequireā argument node --require [file] it allows 3rd party libraries to hook into the ārequire.extensionsā module ts-node tsconfig.file tsc --init āsourceMapā: true Iāve prepared a with a simple Express app that calculates Fibonacci sequences. I recommend you to to follow along, but this is not a requirement for continuing reading this article. GitHub repo clone it $ git clone https://github.com/andrerpena/medium-node-inspector-tests.git $ cd medium-node-inspector-tests $ npm i . If youāre reading this without cloning the repo, use the following as a reference: Iāve also created scripts for all the commands weāll run on this article After your environment is set up, you should be able to and access to see the Fibonacci sequences. npm start localhost:3000/[n] Because I wanted to showcase both JavaScript and TypeScript debugging, Iāve written the first and the has been generated by so it looks a bit ugly. You obviously wonāt have this problem if your code is primarily written in JavaScript. index.ts file JavaScript version tsc Running in DebugĀ mode Weāll explore 2 modes of debugging. Using and . The difference is that the later will not actually start the execution of your code before an agent like Chrome DevTools is attached, and once itās attached, it will automatically break at the first user-code line. --inspect --inspect-brk When a Node.js app is started in āinspectā mode, 2 important things will happen: An will be assigned to this debugging session and a end-point will spin up at . This end-point will stream real-time events with the current state of the running code. UUID WebSockets ws://127.0.0.1:9229/[UUID] An HTTP end-point will spin up at . This allows agents like the Chrome DevTools to know about every running Node session and their respective . [http://127.0.0.1:9229/json](http://127.0.0.1:9229/json) UUID You can . More information : curl [http://127.0.0.1:9229/json](http://127.0.0.1:9229/json) here Debugging JavaScript using the ChromeĀ DevTools Run: npm start:debug // if you're on the suggested repo or...node --inspect index.js // ...otherwise. You should see something like this: You can see a WebSocket server has started on port . You can also notice the is . Each session will have itās own and every time you restart your server this will be different. 9229 UUID 5dc97... Next step is opening Chrome and entering on the address bar. You should see something like this: Chrome://inspect Again, Chrome can automatically detect running sessions by inspecting . Now click to start debugging. A new DevTools window will show up. You can now , (e.g. by pressing on Mac), place your break-points and have fun š: [http://127.0.0.1:9229/json](http://127.0.0.1:9229/json) Inspect navigate to the desired file Cmd + P If instead, you run: npm start:debug:brk // if you're on the suggested repo or... ā¦ youāll notice that will not be immediately available. This is because, due to the argument, Node will only start executing your code after the DevTools or another debugging agent is attached to give you the chance to place break-points beforehand. After clicking , you can now refresh and it will automatically break on the first line of your code. localhost:3000 --inspect-brk Inspect localhost:3000 Debugging TypeScript using the ChromeĀ DevTools It should be almost the same thing we did with JavaScript except that now we should include when running Node. Run: --require ts-node/register npm start:debug:ts node --require ts-node/register index.ts // if you're on the suggested repo or... // ...otherwise. And you should see this: And when you start inspecting on you should now see 2 versions of each TypeScript file: One with source-maps (marked as ) and another one without. Of course, place your break-points on the ones š: Chrome://Inspect [sm] [sm] Everything else should work exactly the same. Debugging JavaScript using the Visual StudioĀ Code Just by selecting the target JavaScript file, clicking on the Debug tab ( on Mac) and hitting the ā¶ļø button should be enough to start debugging the current JavaScript file even without selecting any . VS Code will automatically start Node with the parameter and attach to it. Shift + Cmd + D launch configuration --inspect You can also very easily create a for attaching to a Node process running from the terminal. The VS Code auto-completion for configurations is amazing. This is how the configuration should look like. Remember that is the default port for the Node inspector: launch configuration 9229 Notice that the above configuration doesnāt specify the of the Node session. VS Code, just like Chrome DevTools, will inspect and automatically attach to the current running session if thereās only one. UUID ws://127.0.0.1:9229 After the configuration is in place, run the usual start script from the terminal: npm start:debug // if you're on the suggested repo or...node --inspect index.js // ...otherwise. ā¦ and then select as the and hit the ā¶ļø button: Attach launch configuration Debugging TypeScript using the Visual StudioĀ Code VS Code, when using a configuration will not allow the program to be a file (at least as this article is being written), then youāre left with 2 options: You can either run passing a file as the argument ( returns the currently focused one)ā¦ "type":"node" .ts ts-node .ts ${relativeFile} ā¦ or you can specify the to be NPM (instead of the default: ) and pass a script name as an argument. Both of them have the exact same effect: runtimeExecutable node If you want, instead, to attach to a running TypeScript process spawn from a terminal, it is the exact same script we used for pure JavaScript. Just run the usual script on your terminalā¦ npm start:debug:ts node --require ts-node/register index.ts // if you're on the suggested repo or... // ...otherwise. ā¦ and then attach using the same script we used for pure JavaScript: Debugging JavaScript usingĀ WebStorm On the top-right corner of WebStorm thereās a dropdown where you can set up . Click on it and then select the ā sign to see a list of all available configurations. Select , give it a , and in the field, fill in your entry-point file. That is it. You can now hit the š button and the debug session should start. Run/Debug Configurations Node.js Name JavaScript file Debugging TypeScript usingĀ WebStorm In order to Debug TypeScript, the process is exactly the same as for JavaScript, except that, in the field, you should fill and select your TypeScript file in the field. You can start the debugging session as usual by hitting the š button. Node Parameters --inspect --require ts-node/register JavaScript file I hope you enjoyed it and happy debugging šš«! About theĀ Author Iām , I like writing and building stuff. Recently I built: , a remote job aggregator for developers, check it out! š AndrĆ© Pena https://remoted.io
