Debugging Angular apps created with Angular CLI in WebStorm

Posted on January 31, 2017 by Ekaterina Prigara. Updated on January 2, 2018

Angular CLI can help us bootstrap a new Angular app with a ready to useTypeScript and Webpack configuration. In this post we’ll see how to debug such apps in WebStorm.

If you have never used JavaScript debugger in WebStorm before, we recommend watching this video first to learn how to get started. The same way you can debug Angular apps in IntelliJ IDEA, PhpStorm, PyCharm and RubyMine.

We have an app generating with Angular CLI. We are using version 1.0.0-beta.26 – the latest available at the time of creating this post, the end of January 2017. Please note that Angular CLI is still in beta – new versions are released often and they might introduce some breaking changes.

  • Run npm start to get the app running in the development mode.
    You can do this either in the terminal or by double-clicking the task in the npm tool window in WebStorm.
  • Wait till the app is compiled and the Webpack dev server is ready. Open http://localhost:4200/ to view it in browser.

ng-cli-run

Note that when the dev server is running, the app will automatically reload if you change any of the source files.

  • Create a new JavaScript debug configuration in WebStorm (menu Run – Edit configurations… – Add – JavaScript Debug) to debug the client-side TypeScript code of your app. Paste http://localhost:4200/ into the URL field.

In WebStorm 2017.1 or higher

No additional configuration is needed: save the configuration and you’re ready to go.

In WebStorm 2016 (.1, .2 and .3)

Configure the mapping between the files in the file system and the paths specified in the source maps on the dev server. This is required to help WebStorm correctly resolve the source maps.

The mapping should be between the src folder and webpack:///./src

Add this value to the table with the project structure in the debug configuration like this:

ng-cli-conf
To get this mapping, we investigated the content of http://localhost:4200/main.bundle.map file. This is a source map file for the bundle that contains the compiled application source code. Search for main.ts, the main app’s file; its path is webpack:///./src/main.ts.

  • Save the configuration, place breakpoints in your code and start a new debug session by clicking the Debug button next to the list of configurations on the top right corner of the IDE. The browser will open on http://localhost:4200/.
  • Once a breakpoint is hit, go to the debugger tool window in the IDE. You can explore the call stack and variables, step through the code, set watcher, evaluate variables and other things you normally do when debugging.

ng-cli-breakpoint

There’s a known limitation:

  • The breakpoints put in the code executed on page load might not be hit when you open an app under debug session for the first time. The reason is that the IDE needs to get the source maps from the browsers to be able to stop on a breakpoint you’ve placed in an original source, and that only happens after the page has been fully loaded at least once. As a workaround, reload the page in the browser.

Your WebStorm Team

About Ekaterina Prigara

Ekaterina Prigara is WebStorm product marketing manager at JetBrains. She's passionate about new technologies, UX and coffee.
This entry was posted in Tutorials and tagged , , , . Bookmark the permalink.

52 Responses to Debugging Angular apps created with Angular CLI in WebStorm

  1. Sean says:
    February 1, 2017 at 1:41 pm

    I can say that that debugging works A LOT better in 2017.1 with cli.
    However there still 2 show stoppers to be fixed before so I can say WebStorm is awesome:

    1. var not available with arrow functions: https://youtrack.jetbrains.com/issue/WEB-25133
    2. debug crashes and leaks memory: https://youtrack.jetbrains.com/issue/WEB-25132

    please attend to these issues as I have reported them numerous times,

    Angular 2 Kitchen sink: http://ng2.javascriptninja.io
    and source@ https://github.com/born2net/Angular-kitchen-sink
    Regards,

    Sean

    Reply
  2. Brad S says:
    February 4, 2017 at 2:55 am

    I work in Node.js, serverless-webpack, Typescript. I have no clue on how to get debugger to work in this environment. Is there help for this?

    Reply
    • Ekaterina Prigara says:
      February 6, 2017 at 5:24 pm

      Do you know any open-source app with a similar setup we can try?
      In theory, it should all “just work” if you have source maps (devtool: “source-map” in your Webpack config).

      Reply
  3. Gavin says:
    April 17, 2017 at 3:04 am

    I work in Webstorm 2017 and angular2 with cli and follow every step in your article. When I click the debug button, the chrome show my index page but the breakpoints don’t work at all. What’s more, there is a message in webstorm saying that “WebSocket connection to ‘ws://localhost:4200/sockjs-node/819/wi40mzst/websocket’ failed: Connection closed before receiving a handshake response”.

    Any suggestion to fix it? Thanks a lot!

    Reply
  4. Zuriel says:
    May 19, 2017 at 2:29 pm

    The problem that I have is the inspector kills the debug connection. Which is fine since you are using Jetbrains to debug, but what if you need the responsive viewport features and the touch events. No way to emulate iphone in chrome that I know of without first opening the developer tools. Is there a workaround?

    Reply
  5. Ron Zeidman says:
    June 29, 2017 at 8:30 am

    Webpack has changed their paths so debugging no longer works out of the box.
    This is the correct mapping needed:
    http://localhost:4200/webpack:/
    found it by reading this post: https://blog.jetbrains.com/webstorm/2015/09/debugging-webpack-applications-in-webstorm/ and looked at the “scripts” location in the debug window.

    Reply
  6. Claudio says:
    June 30, 2017 at 7:16 am

    I’m using Webstorm 2017.1.4 and I upgrade my application with angularCli 1.1.3: the debug in webstorm doesn’t works no more (instead the debug in Chrome still works). I try to create an new clean application with angularCli 1.1.3 and the debug in Webstorm still not works.

    Reply
    • Bastian says:
      June 30, 2017 at 9:49 am

      I have the same problem. Using IntelliJ Ultimate 2017.1.4 and angular-cli 1.2.0

      The problem started with the upgrade to angular-cli 1.1.2 (1.1.1 still works fine), with no breakpoints working anymore. Any ideas how to get it up and running again?

      Reply
    • lena_spb says:
      June 30, 2017 at 10:05 am

      This is likely the problem caused by recent angular-cli changes: currently webpack generates absolute Windows paths in sourcemap that break the debugging (https://youtrack.jetbrains.com/issue/WEB-27381).

      As a workaround, please, try the following:

      – in terminal, run ng eject in project root directory
      – open the generated webpack.config.js, in line 385 change moduleFilenameTemplate value to info =>webpack:///${info.resourcePath}:

      new SourceMapDevToolPlugin({
      "filename": "[file].map[query]",
      "moduleFilenameTemplate": info =>      webpack:///${info.resourcePath},
      "fallbackModuleFilenameTemplate": "[resource-path]?[hash]",
      "sourceRoot": "webpack:///"
      }),

      – run npm start to start the application, then use your JavaScript debug configuration for debugging

      Reply
      • Oskar Emil Skeide says:
        April 9, 2018 at 7:53 am

        I this still an issue ?

        Using angular-cli 1.7.3 and WebStorm 2018.1 I have followed the instructions in the blog post but breakpoints in WebStorm are not hit.

        Reply
        • Ekaterina Prigara says:
          April 9, 2018 at 8:54 am

          Hello,
          Can you please share a bit more information about your app and where the breakpoints exactly are.
          We have tried to debug an app generated with Angular CLI 1.7.3 on Windows and the breakpoints put in the event handlers work fine.
          The workaround suggested in another comment applies only to WebStorm 2017.1 and earlier.

          Reply
    • Ron Zeidman says:
      July 3, 2017 at 6:06 pm

      You can eject like lena_spb said or just add at the Run/Debug configurations the following path:
      http://localhost:4200/webpack:/(Your full path)

      Reply
  7. Lukas says:
    July 11, 2017 at 2:08 pm

    For me it just works fine (using IntelliJ 2017.1.5 and Angular 4 with custom webpack 2 setup which is still a leftover from our angular 2 setup).

    However, I can see the objects passed to or declared in any function I debug but I cannot see the values of any member variable. IntelliJ says that all of them are undefined, even after they’ve got assigned a static value during the debug operation.

    I configured webpack to use devtool: 'source-map' and already tried to map the remote url to the full path, but nothing changed.

    Can anyone help me please?

    Reply
    • Lukas says:
      July 11, 2017 at 2:35 pm

      I found a solution. I changed the devtool to devtool: eval-source-map which seems to work now.

      Thanks for this nice tool!

      Reply
  8. TomN says:
    August 24, 2017 at 11:39 pm

    Is Live Editting possible with angular CLI/webpack and webstorm? If so how?

    Reply
  9. NairN says:
    October 24, 2017 at 12:08 pm

    Hello!

    I have been trying to debug an Angular CLI application with a NodeJs back end server. Both are running on the same machine and using default ports. I have followed the instructions as mentioned on this page and also tried some other options, but I can’t get Webstorm to debug properly. I have the chrome plugin installed. I am using the latest version of Webstorm.
    Every time that I click the debug option with the custom configuration settings mentioned here the page does not load. If I open the page on another tab then the page loads. However, I need to wait about ~2 mins for the debugger to stop at the first break point. I don’t know what’s happening. Please help.

    Reply
  10. Graham Tilson says:
    December 3, 2017 at 12:45 pm

    I’m debugging an Angular 4 CLI app using PHP Storm 2017.2.4. So I can set the breakpoints in Chrome and it will stop at that line in Storm and allow me to view variables and step forward etc. That’s all great, but what I really want to do is set the breakpoint in Storm and that bit doesn’t seem to work.

    Reply
    • Ekaterina Prigara says:
      December 4, 2017 at 12:07 pm

      Can you please provide a bit more details: what exact @angular/cli version do you use? what happens with the breakpoints put in the editor?

      Reply
  11. Mathieu Paquette says:
    December 15, 2017 at 4:14 pm

    Hello, just tried this tutorial with Angular-CLI 1.6 with IntelliJ Ultimate 2017.3 and all my breakpoints aren’t hit. I’m using the same exact setup with an older version of CLI and this is working fine. Could you please revise your work with the latest version and tell me what’s going on? Thank you very much.

    Reply
  12. Sebastian says:
    December 18, 2017 at 6:55 am

    Could you update the blog post to reflect the latest changes in 2017.3?

    Reply
    • Ekaterina Prigara says:
      December 18, 2017 at 1:38 pm

      Hi Sebastian,
      What changes exactly do you mean? That you can have Chrome DevTools open? The blog post doesn’t mention that you can’t. And it doesn’t change the steps you need to do debug the app in WebStorm, does it?

      Reply
  13. Sebastian says:
    December 18, 2017 at 6:56 am

    It seems that its now possible to have devtools open in chrome while debugging with IntelliJ.

    Reply
  14. Ryan P says:
    January 15, 2018 at 10:16 pm

    I’m pulling in my webpack bundled files (served locally using ng serve at http://localhost:4200/dist) into a website that is running at http://localhost:58177, but the breakpoints aren’t being hit. The main site, on port 58177, serves up the tags to the webpack files on port 4200. Am I missing something?

    Reply
  15. andrea says:
    January 19, 2018 at 4:56 pm

    Hello,

    I have followed the instructions in this post, and everything works fine, apart from a detail.
    Breakpoint are not being hit during the bootstrap of the applications. Afterwords, during the usage of the application, they are hit.

    I’m using Intellij Ultimate 2017.3
    The version of the cli is 1.6.4

    I’ve created a new app with “ng new” and added some code just to have a place where to put the breakpoints.

    import {Component, OnInit} from ‘@angular/core’;

    @Component({
    selector: ‘first-shipping’,
    templateUrl: ‘./shipping.component.html’,
    styleUrls: [‘./shipping.component.css’]
    })
    export class ShippingComponent implements OnInit {

    constructor() {
    console.log(constructor); //BREAKPOINT 1 here
    }

    ngOnInit() {
    }

    onClick() {
    console.log(onclick); //BREAKPOINT 2 here
    }

    }

    During the boostrap, the constructor is called but the breakpoint 1 is ignored.
    When i click on the button bound to onclick method, the app correctly stops at breakpoint 2.

    Workaround: if I put breakpoint 1 in Chrome instead of Intellij, the breakpoint is not ignored.

    Reply
    • Ekaterina Prigara says:
      January 22, 2018 at 10:31 am

      Hello, please see the limitation described in the last paragraph of this blog post. The breakpoints in the code that is executed on page load might not be hit when you start the app for the first time: WebStorm needs to load the source maps to resolve them and it might not happen by the time the code under the breakpoint is executed.

      Reply
  16. Alan Clarke says:
    March 14, 2018 at 2:59 pm

    These instructions do not work! Webstorm 2017.3.5. This is an absolute deal breaker in terms of me continuing to pay for a subscription for this software when it cannot even debug.

    Reply
    • Ekaterina Prigara says:
      March 14, 2018 at 4:35 pm

      Hello Alan,
      Sorry to hear that you had a problem with the debugger.
      Can you please provide a bit more details about it? What Angular CLI version do you use? Where the breakpoint is put?
      We have just tested debugging a project created with @angular/cli 1.7.3 and everything worked fine.

      Reply
      • Alan Clarke says:
        March 14, 2018 at 6:09 pm

        I upgraded @angular/cli from 1.6.4 to 1.7.3, works with newer angular-cli but not fully backwards compatible for older versions.

        Thank you for checking the issue and providing a solution.

        Reply
        • Alan Clarke says:
          March 14, 2018 at 6:11 pm

          It still does not work, breakpoints are not triggered. Cannot pay for such software.

          Reply
          • Ekaterina Prigara says:
            March 15, 2018 at 12:55 pm

            I’ve have just tried debugging the app generated with @angular/cli 1.6.6 (it ‘s not possible to generate a new project with version 1.6.4 anymore because of the broken @angular-devkit/core dependency) and it also worked fine – the breakpoint put in the click handler (as on the screenshot in the post) was hit.
            Please contact our technical support and provide a sample project if you want to investigate the issue you have further.

  17. Gerard Carbó Ibars says:
    April 19, 2018 at 11:02 am

    Not working with WebStorm 2018.1.1 and @angular/cli 1.7.4, neither on npm test or start tasks. Frozen in ‘Connecting to localhost:55464’

    Reply
  18. Marc says:
    April 26, 2018 at 4:24 am

    I am running Version: 2018.1.2 and get the below message when running Debug as instructed in the above article.

    Waiting for connection to localhost:24085. Please ensure that the browser was started successfully with remote debugging port opened. Port cannot be opened if Chrome having the same User Data Directory is already launched.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *