
We can add and remove breakpoints any time during the debug session or before it. For example, you can add specific conditions when the breakpoint will be hit. You can additionally configure how the breakpoint works if you right-click on it. If you click on a breakpoint again, it will be removed. (Here’s the content of the file on this screenshot) Let’s put a breakpoint on a line in which our demo app handles the GET request: click next to the line number in the editor, and you will see a red circle, a breakpoint.
#Webstorm debug electron code
With the breakpoints, we can pause the app when a specific line of code is executed and then look at the application state: what variables are now available and what their values are. Now we want to see what’s going on in our app at a specific point. We can double-click on the file to see its content in the editor. The Scripts tab lists all the files loaded into the currently running process. The Console tab shows the messages logged by the app as well as error messages, but we can also use it to evaluate expressions. The Debug tab with Frames and Variables view as well as the stepping icons on top will be activated when the app is stopped on a breakpoint (we’ll talk about it in a moment). On the left side of it, there are the icons for stopping and re-running our configuration. We can now see a new Debug tool window at the bottom of the IDE – it’s a control panel for everything related to debugging. This creates a temporary configuration that, if you want to reuse it, you can save later in the Edit configurations dialog (temporary configs are greyed out).
#Webstorm debug electron windows
Instead, we could have right-clicked on the JavaScript file in the project view or the editor and selected Debug or pressed Ctrl-Shift-D or Ctrl-Shift-F9 on Windows and Linux. In our case, we could have actually started a debugger without creating a configuration beforehand. Many configurations will do the same, but some other will instead attach the debugger to the already running app. Our Node.js configuration will run the file we’ve specified in it in a debug mode. Once we have our configuration ready, select it in the drop-down list and hit the green debug icon (the one with the bug on it). idea/runConfigurations folder to the version control. If you want to share your configuration with your team, check the Share checkbox in the configuration and then commit the. idea folder in the root of your project so that you can reuse them next time you open this project.


Some configurations attach to the already started app, in this case, you need to specify the URL and port to attach to. In the test configuration you can select between the name of a suite, test or a test file. To debug different types of apps and files, you need to use different types of run/debug configurations.ĭepending on the type, the information you need to provide in the configuration varies.įor example, in the Node.js configuration, you need to specify a file that needs to be run. Run/debug configuration is an entry point to, as the name suggests, running and debugging apps in WebStorm.

Prepare for debugging: create a run/debug configuration Then we’ll put in some breakpoints, see what’s going on in the Debugger’s Variables view, step through the code, evaluate expressions and use the interactive console. We’ll start with creating a new run/debug configuration. To see how the debugger works in WebStorm, we’ll try to debug a simple Express Node.js application. If you want to edit the code or quickly navigate to the usages or definitions of methods while debugging, you don’t need to switch back to the editor.Īnd no matter what kind of code you debug, your experience with the debugger will be the same. One of the main benefits of using a debugger inside the IDE is that you put the breakpoints and step through your actual source code (even if you then compile it.

In addition to that, you can also debug unit tests and build scripts. With WebStorm you can debug all kinds of applications written in JavaScript, TypeScript or Dart: Node.js, React Native and Electron apps and, of course, client-side apps written using different frameworks. The debugger is one of the most essential features of WebStorm.
