{"id":22853,"date":"2018-01-23T16:28:56","date_gmt":"2018-01-23T16:28:56","guid":{"rendered":"https:\/\/blog.jetbrains.com\/webstorm\/?p=9421"},"modified":"2024-01-25T14:14:26","modified_gmt":"2024-01-25T13:14:26","slug":"how-to-debug-with-webstorm","status":"publish","type":"webstorm","link":"https:\/\/blog.jetbrains.com\/zh-hans\/webstorm\/2018\/01\/how-to-debug-with-webstorm","title":{"rendered":"How to Debug With WebStorm"},"content":{"rendered":"

Note: This post was updated in January 2024.<\/em><\/p>\n

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

One of the main benefits of using a debugger inside the IDE is you can add breakpoints and step through your source code (even if you then compile it. Thank you, source maps!). If you want to edit the code or quickly navigate to the usages or definitions of methods while debugging, you don\u2019t need to switch back to the editor.<\/p>\n

And no matter what kind of code you debug, your experience with the debugger will be the same.<\/p>\n

To see how the debugger works in WebStorm, we\u2019ll try to debug a simple Express<\/a> Node.js application generated by the New Project<\/em> wizard<\/a>. We\u2019ll start by creating a new run\/debug configuration. Then, we\u2019ll add some breakpoints, see what\u2019s happening in the Debugger\u2019s Variables<\/em> view, step through the code, evaluate expressions, and use the interactive console.<\/p>\n

Prepare for debugging: create a run\/debug configuration<\/strong><\/h2>\n

Run\/Debug Configurations<\/em> is an entry point to, as the name suggests, running and debugging apps in WebStorm.<\/p>\n

To debug different types of apps and files, you need to use different types of Run\/Debug Configurations<\/em>.<\/p>\n

Depending on the type, the information you need to provide in the configuration varies.
\nFor example, in the Node.js<\/em> configuration, you need to specify a file to run. In the test configuration, you can select the name of a suite, test, or test file. Some configurations attach to the already started app. In this case, you need to specify the URL and port to attach to.<\/p>\n

To create a run\/debug configuration:<\/p>\n

    \n
  1. Click the drop-down list on the toolbar and select Edit configurations\u2026<\/em>. The Run\/Debug Configurations<\/em> dialog opens.<\/li>\n
  2. In the left-hand pane, click the +<\/em> icon on the toolbar and select the configuration type: we\u2019ll choose Node.js<\/em>.<\/li>\n
  3. In the right-hand pane, add the missing information about the debug environment: we need to specify bin\/www<\/code>, which is the main file that runs our app.<\/li>\n
  4. Name and save the configuration.<\/li>\n<\/ol>\n

    \"Create
    \nAll the created configurations are saved in the workspace.xml<\/em> file in the .idea<\/em> folder in the root of your project, so you can reuse them the next time you open this project.<\/p>\n

    If you want to share your configuration with your team, check the Share<\/em> checkbox in the configuration and then commit the .idea\/runConfigurations<\/em> folder to the version control.<\/p>\n

    Starting the debugger<\/strong><\/h2>\n

    Once our configuration is ready, select it from the drop-down list on the toolbar and click the green debug icon next to it.<\/p>\n

    \"Start<\/p>\n

    Our Node.js<\/em> configuration will run the file we specified in debug mode. Many configurations will do the same, but some others will instead attach the debugger to an already running app<\/a>.<\/p>\n

    In our case, we could have started the debugger without creating a configuration beforehand. Instead, we could have right-clicked the bin\/www<\/code> JavaScript file in the Project<\/em> tool window or the editor and selected Debug<\/em>, or we could have pressed ^D<\/em> on macOS or Ctrl+Shift+D<\/em>\/Ctrl+Shift+F9<\/em> on Windows and Linux.<\/p>\n

    \"Start<\/p>\n

    This creates a temporary configuration that, if you want to reuse it, you can save later in the Run\/Debug Configurations<\/em> dialog (temporary configurations are greyed out).<\/p>\n

    \"Saving<\/p>\n

    Debug tool window<\/strong><\/h2>\n

    We can now see a new Debug<\/em> tool window at the bottom of the IDE \u2013 a control panel for everything related to debugging.<\/p>\n

    The toolbar above it shows icons for stopping and re-running our configuration and for stepping through the application.<\/p>\n

    The Frames<\/em> and Variables view<\/em> will be activated when the app stops at a breakpoint (we\u2019ll talk about it in a moment).<\/p>\n

    The Debugger Console<\/em> tab can be used for evaluating expressions.<\/p>\n

    \"Debug<\/p>\n

    The Process Console tab<\/em> shows the messages logged by the app and error messages.<\/p>\n

    The Scripts tab<\/em> lists all the files loaded into the currently running process. We can double-click on the file to see its content in the editor.<\/p>\n

    Adding breakpoints to pause the code<\/strong><\/h2>\n

    We want to see what\u2019s going on in our app at a specific point. 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.<\/p>\n

    Let\u2019s put a breakpoint on a line in which our demo app handles the GET<\/code> request: click the line number in the editor, and you will see a red circle, a breakpoint.<\/p>\n

    \"Setting<\/p>\n

    (Here\u2019s the content of the file<\/a> on this screenshot)<\/p>\n

    If you click the breakpoint again, it will be removed. You can additionally configure how the breakpoint works if you right-click it. For example, you can set specific conditions for hitting the breakpoint.<\/p>\n

    \"Conditional<\/p>\n

    We can add and remove breakpoints any time during the debug session or before it. There\u2019s no need to restart the debugger after we\u2019ve set or cleared a breakpoint!<\/p>\n

    Exploring the app state and call stack<\/strong><\/h2>\n

    So now, when the debugger is up and running and we have a breakpoint in our code, let\u2019s stop on it. For that we should do the actions that will trigger the code with the breakpoint: in our case, we need to open the browser at http:\/\/localhost:3000\/en<\/code>.<\/p>\n

    Now, the Debug<\/em> tool window is full of content. Let\u2019s have a look at what is going on!<\/p>\n

    On the right, we see the state of our application \u2013 all the local and global variables available at this point and their values. We can also see the values right in the editor: at the end of the lines of code or if we hover over a variable.<\/p>\n

    \"Debug<\/p>\n

    The Threads<\/em> view shows the call stack \u2013 a list of all the methods that have been executed to get the execution to the code with the breakpoint in reverse chronological order. If we go through the frames, we will see the application\u2019s state at every point of the execution path.<\/p>\n

    Don\u2019t forget that the code under the breakpoint has not yet been executed. So, if you introduce a variable in this line, you\u2019ll see it in the Variables view<\/em>, but it will still be undefined.<\/p>\n

    We can expand the objects and arrays to see their content in the Variables view<\/em>.<\/p>\n

    We are specifically interested in the params<\/code> object that contains the parameters of the request. We can type its name to find it in the list (note that it will search only through the expanded nodes). Let\u2019s add it to Watches<\/em> \u2013 that way, we will always see its value on the top of the Variables view<\/em> anytime we stop at a breakpoint.<\/p>\n

    \"Adding<\/p>\n

    Now press the Resume Program<\/em> button on the toolbar to continue executing the program.<\/p>\n

    \"Resuming<\/p>\n

    Stepping through the code<\/strong><\/h2>\n

    If we want to get a better understanding of how our code is executed, we, of course, can put lots of breakpoints in our code and then move from a breakpoint to a breakpoint by resuming the execution, but there\u2019s a better way \u2013 we can step through the code!<\/p>\n

    The stepping actions are available on the top of the debug tool window and activated when the breakpoint is hit.<\/p>\n

    Step over<\/em> action (F8<\/em>) will move the execution in the current file, line by line, without stepping into any function calls.<\/p>\n

    \"Step<\/p>\n

    In our example, if we hit it once, it will check the condition in line 10 and then stop on the statement in the else block because the condition was false.<\/p>\n

    With Step Into<\/em> (F7<\/em>), we will step to the next executed line in this or another file. So, if it\u2019s a function call, it will jump to its definition and stop at the first line.<\/p>\n

    \"Step<\/p>\n

    By default, WebStorm will not step into the source code of JavaScript, Node.js, or dependencies in the node_modules<\/em> folder of your project. But if you want to step into them, you can use the Force Step Into<\/em> action (you can clear the Do not step into libraries<\/em> checkbox in Settings | Build, Execution, Deployment | Debugger | Stepping<\/em>).<\/p>\n

    Step Out<\/em> (\u21e7F8<\/em> \/ Shift+F8<\/em>) will finish executing the current function and stop at the next statement after the call.<\/p>\n

    If we want to skip some lines but then stop on another line that is not yet executed, we can either put a new breakpoint on this line and press Resume<\/em> or put a cursor in it and use the Run to Cursor<\/em> action. Which is a much easier and more efficient way than setting and clearing breakpoints whenever you move the cursor.<\/p>\n

    Evaluate Expression<\/strong><\/h2>\n

    The Variables view<\/em> shows the values of objects when the app is stopped on a breakpoint. But what if we want to check the value of an expression? For instance, we want to see if a condition in the if statement is true or false before we step over to the next line.<\/p>\n

    There are three ways you can do this:<\/p>\n

    The first way is to type the expression in the Debugger Console<\/em>. For that, we can either type it or copy and paste it.<\/p>\n

    \"Evaluating<\/p>\n

    A second way is to select the expression and then use the Quick Evaluate Expression<\/em> action (\u2318\u2325F8<\/em> \/ Ctrl+Alt+F8<\/em>): the result will appear next to it in a tooltip.<\/p>\n

    \"Quick<\/p>\n

    And a third way is to invoke the Evaluate Expression<\/em> popup. Similar to the console, you can type (with the help of code completion) and evaluate any statement it is in.<\/p>\n

    \"Evaluate<\/p>\n

    The pros of using the Evaluate Expression<\/em> popup compared to the console are that you can open it using a shortcut (\u2325F8<\/em> \/ Alt+F8<\/em>) and then see all the information about the returned object in a handy tree view.<\/p>\n

    \"Evaluate<\/p>\n

    So now we know enough to debug an application: we can stop the app on a breakpoint, see the application state, step through the code, and evaluate expressions. It all works the same way in WebStorm, no matter what kind of app you are debugging.<\/p>\n

    That’s it for today. You can also find lots of helpful information in the WebStorm documentation<\/a>.<\/p>\n

    The WebStorm team<\/em><\/p>\n","protected":false},"author":221,"featured_media":433684,"comment_status":"open","ping_status":"closed","template":"","categories":[601],"tags":[632,264,263],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/webstorm\/22853"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/webstorm"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/types\/webstorm"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/users\/221"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/comments?post=22853"}],"version-history":[{"count":7,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/webstorm\/22853\/revisions"}],"predecessor-version":[{"id":437779,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/webstorm\/22853\/revisions\/437779"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/media\/433684"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/media?parent=22853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/categories?post=22853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/tags?post=22853"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/zh-hans\/wp-json\/wp\/v2\/cross-post-tag?post=22853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}