Debugging Angular apps created with Angular CLI in WebStorm

Angular CLI can help us bootstrap a new Angular app with a ready to use TypeScript 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. You can see the app running in the browser ot http://localhost:4200/.


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

  • Check if a run/debug configuration named Angular Application already exists in WebStorm. If not, 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.
  • 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.


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.
In WebStorm 2016 (.1, .2 and .3)
In this IDE versions, you need to configure the mapping between the files in the file system and the paths specified in the source maps on the dev server in your debug configuration. This is required to help WebStorm correctly resolve the source maps.The mapping should be between the src folder and webpack:///./srcAdd this value to the table with the project structure in the debug configuration.To get this mapping, we investigated the content of http://localhost:4200/ 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.

If you have any problems with debugging your application, please contact our tech support. Please share information about your IDE version and breakpoint locations and, if possible, your project.

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.

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

  1. Sean says:

    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:
    2. debug crashes and leaks memory:

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

    Angular 2 Kitchen sink:
    and source@


  2. Brad S says:

    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?

    • Ekaterina Prigara says:

      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).

  3. Gavin says:

    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!

  4. Zuriel says:

    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?

  5. Ron Zeidman says:

    Webpack has changed their paths so debugging no longer works out of the box.
    This is the correct mapping needed:
    found it by reading this post: and looked at the “scripts” location in the debug window.

  6. Claudio says:

    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.

    • Bastian says:

      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?

    • lena_spb says:

      This is likely the problem caused by recent angular-cli changes: currently webpack generates absolute Windows paths in sourcemap that break the debugging (

      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 =>
      "fallbackModuleFilenameTemplate": "[resource-path]?[hash]",
      "sourceRoot": "webpack:///"

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

      • Oskar Emil Skeide says:

        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.

        • Ekaterina Prigara says:

          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.

    • Ron Zeidman says:

      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)

  7. Lukas says:

    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?

    • Lukas says:

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

      Thanks for this nice tool!

  8. TomN says:

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

  9. NairN says:


    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.

  10. Graham Tilson says:

    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.

    • Ekaterina Prigara says:

      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?

  11. Mathieu Paquette says:

    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.

  12. Sebastian says:

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

    • Ekaterina Prigara says:

      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?

  13. Sebastian says:

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

  14. Ryan P says:

    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?

  15. andrea says:


    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’;

    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.

    • Ekaterina Prigara says:

      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.

  16. Alan Clarke says:

    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.

    • Ekaterina Prigara says:

      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.

      • Alan Clarke says:

        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.

        • Alan Clarke says:

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

          • Ekaterina Prigara says:

            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:

    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’

  18. Marc says:

    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.

  19. sweet says:

    forget all this. just use ng new project-name from npm install @angular/cli

    they generate the intellij project folder for you with run configs.

    it just works.

  20. Paul says:

    Are there updated instructions for Webstorm 2019? I’m attempting to debug an Angular 7 app and following the details above, my breakpoints don’t trigger.

    1. Add Angular application debug config (localhost:4200, no other settings applied)
    2. Add breakpoint within a component method
    3. ng serve
    4. Run configuration from step 1 (Chrome opens)
    5. Perform action that calls breakpoint-containing method
    6. Breakpoint does not trigger

    • Ekaterina Prigara says:

      Hello Paul,
      The steps you have followed should work. We couldn’t reproduce the problem in a simple app. Can you please share a project or some screenshots showing where the breakpoints are set? Is the breakpoint hit after you reload the page in the browser?

  21. Mariusz says:


    i got the issue of debug not working for lazy loaded modules in Angular. Component/Service code from core/shared modules stops correctly but any code from lazy modules is ignored. I get the green breakpoint circles for code from regular modules and the circles are red for code from lazy loaded modules.

    Are lazy modules supported?

    Things ive tried:
    – as described in this article
    – in addition installed JetBrains IDE Support extension (chrome) and activated it under Build, … > Debugger > Live Edit and this has shown the same behaviour (regular modules debuggable, lazy loaded modules are not)

    Iam using Chrome on macOS, current Angular 7 (new project).


    • lena_spb says:

      Hi Mariusz,

      debugging lazy loaded Angular modules works fine for us. Please can you create a new support ticket, providing the detailed information about your setup? The sample project that shows up the issue would be appreciated

  22. meanstack says:

    the latest jetbrains refuses to hit breakpoints in typescript on a windows angular app runnign oin https

    it keeps loading the main.js operating breakpoints out of THAT

    reloading the browser from the IDE Extension does nothing and the app runs with no breakpoints being hit


    this document does not cut it

    and this product is high risk for commercial field contracting

    when it refuses to hit the breakpoints inside my typescript file

    read all the threads and docs and tried everything

    eager loaded modules

    blue in the face

  23. meanstack says:

    helloworld simple apps are not qualifying as an example to prove this product SHOULD do what its suppose to

    the threads on this are unending and its never resolved

  24. meanstack says:


    if you want to do a remote web session

    I will devote some time for you to repair your product

    I have a signiicant app causing this issue

    I wont post anything online

    I do zoom

    contact me at and we can proceed and we can help get your product up to snuff and you can see what is preventing it from operating on my machine

    I prefer webstorm over vscodeand I will extend my time and help to get this working

    but many in the field are veay wary of this not happening we are trying to perform in the field and its critical to be able to debug typescript with seamless fast live reload of typescript thru sourcemaps

    – cheers


  25. Marc says:

    I’m echoing Meanstack/Ken’s comment. I’ve opened up a request but could never get it resolved. Zoom / Remote control didn’t seem to be an option. But I am really discouraged at Webstorm / IntelliJ not working on this. This problem (possibly perpetuated by constant changes in Angular) just seems to have been dragging on forever.

    • Ekaterina Prigara says:

      Hello Marc, can you please share a bit more information about the problem? Can you send a link to the request?

  26. Artur says:


    I have the same problem as above. Can’t debug Angular app in Intelij IDEA (or WebStorm).
    We use lazy loading modules too. But I can’t share the code. It’s commercial one.

    • Ekaterina Prigara says:

      Hello Artur, we would really appreciate it if you share some sample project that would help us better understand the project configuration you have and the problem you’re experiencing. Does this problem happens if you debug your app in Chrome’s DevTools?

      • Artur says:


        ok, I will try to make a sample project later.
        There is no problem when I try to debug the project in VS Code. But I prefer WebStorm..

  27. Patrik J says:

    I thought that debugging in VS Code was a pain but at least that works, unlike anything I have tried in WebStorm using numerous tutorials. This just makes the entire IDE pointless and I see no reason paying for it, especially since it seem to have been a problem for MANY years and never gets fixed.

    • Ekaterina Ryabukha says:

      Hi, could you kindly clarify what exactly is not working as expected? Have you tried creating an issue regarding your problem so that we could help you solve it? If not, please create one here:

      • Patrik J says:


        Please provide a working guide/tutorial for latest WebStorm on how to get a single breakpoint working in WebStorm debugger with a new angular application generated by the Angular CLI, using latest version of Chrome and latest version of NodeJS. Everything installed with default settings. This is more than I have been able to manage for a few days now, and based on other comments over the years, I am far from the only one with these problems.

        Lets say the breakpoint should be this:

        export class AppComponent {
        title = ‘nameofapp’;


        • Patrik J says:

          Or even better, a video of how to do it, that unlike the one linked to at the top of this page actually work. Thanks.

          • Patrik J says:

            I was actually able to make this work by ignoring written instructions but instead “figure it out”. If it still works fine in a day or two, I will return with a guide on how to do it.

          • Ekaterina Ryabukha says:

            Hi, please keep us posted on how it works and, if possible, let us know which steps worked for you. Meanwhile, we’ll review the information provided in this blog post and think about whether it can be improved somehow.

Leave a Reply to Tim Benke Cancel reply

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