Now, on the WebStorm side, we need to add a new Run/Debug configuration. (💡 Quick tip: for easier local Node.js backend application development, make sure you utilize the nodemon library. If you see this, then we're ready for the next step! Notice the message Debugger listening on ws://127.0.0.1:9001/. Now, if you were to run the above command, you should receive the following output: The following is the code that makes this possible: const express = require("express") Ĭonsole.log(chalk.cyan(`🚀 App running on port $.`)) Note that the -port=9000 argument is handled in my application code, and it's here because you usually want to give developers the ability to change the port on which the application will be running on their local machine. The port 9000 will be used by my Express app. So, 9001 is the port on which the Node.js process will listen for the debugging client (in my case - Webstorm IDE's client). In the following command, I'm using port 9001: nodemon scripts/app.js -port=9000 -inspect=9001 Note that you don't have to use the default 9229 port. Each process is also assigned a unique UUID". By default, it will listen at host and port 127.0.0.1:9229. If you were wondering what exactly it does, there is a good and short explanation over at the official docs: "When started with the -inspect switch, a Node.js process listens for a debugging client. The first step is to start your Node.js server, but with the special -inspect switch. So, in this short article, we'll see how to set this up in just two simple steps. And although the process to set it up ultimately wasn't too complicated, at the time of writing this article, I still couldn't find an easy step-by-step guide on how to do it.
The other day, I wanted to debug a locally running Node.js / Express powered API endpoint, using my favorite IDE - WebStorm. (To learn more about the Node.js's debugger, check out the official documentation). A much better alternative is to use the Node.js debugger, which is a tool I basically can't live without these days. And while in certain cases this can still be a quick way to perform code inspection, in general, it is a very slow and painful approach to determine what's wrong with our code.
CLDD) methodology in order to debug our app 😉. That's why it is important that we have our development environment and tools ready for the task.Īt one point in time, as developers who also live in the JavaScript / Node.js world, I'm sure we've all used the famous " console.log driven development" (a.k.a. As developers, finding and resolving bugs within our applications is something we do every day.
0 kommentar(er)
