neroking.blogg.se - Webstorm node debugger

#WEBSTORM NODE DEBUGGER UPDATE#
#WEBSTORM NODE DEBUGGER PC#

Azure has no way to SSH into an App Service on Linux directly.

#WEBSTORM NODE DEBUGGER PC#

Port forwarding from our own PC to the environment in Azure.

An SSH connection to our App Service on Linux.

The blog post about setting up an SSH tunnel with App Service on Linux explains this in much more detail, but in order to be able to attach to the Node.js debugger, we will need two things: Adding the -inspect flag means my startup command in Azure will become: I am using a boilerplate Express app for which the normal startup command is node. In the Azure portal, under our app’s Application settings, we can specify the startup file. The good thing is development of many Azure things happens in the open! A bit of searching revealed a pull request containing the required magic, and let me to discovering the one thing needed to get the Azure side of things set up: starting our app with the -inspect flag.

Unfortunately, that did not work for me… At time of writing (see this post’s publish date), debugging Node.js on App Service on Linux is still in preview and my guess is not all regions have the required magic deployed. On the Azure side, there is only one thing that has to happen: our Node.js application has to run with node’s -inspect flag.Īnd great news! As described in a post by Kenneth Auchenberg, things should “just work ™”! Other thing we will need, of course, are an active Azure subscription, as well as an App Service on Linux that we can play with.

#WEBSTORM NODE DEBUGGER UPDATE#

(or az extension update -name webapp if already installed) To get it, open a command prompt, make sure the az command is on the PATH, and run: The latest version of the Azure CLI 2.0.Sweet! But… how? The blog post did not mention a lot of details on the debugging part, so let’s walk through it, shall we? Remote debugging of Node.js apps on Azure App Service from WebStorm! Prerequisitesįirst of all, we will need a number of things on our machine: Remote debugging, in public preview: You can now choose to remote debug your Node.JS applications running on App Service on Linux. One that I was interested in was this one: Switching IDEs can be a bit annoying (and a RAM hog if you have both open at the same time), but it allows me to use the best tool for the job, so I find it's worth it in the end.Remote debugging of Node.js apps on Azure App Service from WebStorm Edit on GitHubĪt Microsoft Build 2018, a number of Azure App Service on Linux enhancements were announced. In reality, I usually have both IDEs open at the same time and switch to the one that meets my needs best for the particular task I'm working on. Also, I may find myself missing GitHub copilot suggestions when coding in WebStorm, but right now I don't feel that way (possibly because I haven't used GitHub copilot enough). the Prisma extension that can format prisma schema files on save). That being said, there are some times where I'm coding in WebStorm and want to benefit from a VSCode extension (e.g. I've found myself switching over to WebStorm while working in VSCode if I need to do some significant refactoring. If I had to pick a single editor, I would pick WebStorm due to its superior refactoring capabilities.

The past couple of weeks I've been switching between both VSCode and WebStorm for the sake of being able to compare both editors accurately. The only thing I've noticed that WebStorm does better than VSCode is that WebStorm will switch to the correct TypeScript version based on which file you're editing in the monorepo, whereas VSCode doesn't do that. Both editors seem to be able to handle opening projects at the root of a monorepo and still provide working autocompletion and formatting on save.