![]() ![]() 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. (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: This approach is not only working for Angular 2, but for other JavaScript applications, too.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. If you use gulp-sourcemaps you can use the sourceRoot attribute to set the correct folder, like we did in BoardZ. In case your WebStorm/Chrome does not stop at your set breakpoint, your source root of your source maps points to the wrong folder. You can now add a breakpoint in your TypeScript files and start debugging! Cool, eh? -) If everything works, Chrome shows a little note at the top of the page, that JetBrains IDE Support is debugging this browser. You need to go to the extension and change the port to whatever WebStorm wants. WebStorm will tell you which port it uses for the connection to the extension. If WebStorm complains that it cannot find a running JetBrains IDE Support then the port it tries to reach is wrong. WebStorm will now attach itself to the installed Chrome extension (or opens a browser at first, if it is not open yet). If done, click on that little Bug icon in WebStorm (and be sure, that the correct configuration is selected). For BoardZ that's a simple npm run watch. Start all the scripts you need to run your web application. There should now be an entry pointing to your project. If everything is running smoothly, as it should, WebStorm automatically populates the list of Remote URLs of local files. Per default, BoardZ! is hosted on so I put into the URL field. In URL you put in the URL where you web application is hosted. A new dialog will open, where you click on the little plus icon at the top left and select JavaScript Debug.Īt next you need to set some settings on the newly opened right side. Within WebStorm, go to Run -> Edit configurations. So if the build process of your web app does not create source maps yet, you need to do this first.įor this demo I'm using the BoardZ! Cross Platform Sample Application which fortunately already creates source maps. Since we want to debug Angular 2, which uses TypeScript, we need to create source maps, too. Now switch to your beloved WebStorm and open the project you want to debug. Especially the port should be noted (which defaults to 63342).Ī left click on the fancy JetBrains icon will switch to your IDE, if it is open. A new page will open, showing you Host and Port. Alternatively go to chrome://extensions, scroll to JetBrains IDE Support and click Options there. After installing, you get a fancy new icon within Chrome. To start using WebStorm as your debugger, you need to install a Chrome extension called JetBrains IDE Support. I've got a "debug stack" in my head which is visually presented by all open files in WebStorm making it much more easy to jump around in the source code. Most of the time, all necessary files are already open in my IDE, since I'm currently working on them. But sometimes there are cases, where I want to use WebStorm for debugging. When it comes to debugging, I spin up my Chrome Developer Tools and debug along. Most of the time I have a fullscreen WebStorm on my primary and Chrome on my secondary screen. WebStorm is my favorite choice when it comes to develop web applications especially with Angular 2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |