WebStorm refusing to stop at many breakpoints while debugging Jest tests in IDE

Today, I cannot convince WebStorm to stop at many of my breakpoints when I'm debugging Jest tests.

Current WebStorm version: 2020.2.1.  What other versions you want?

My workflow is, I have a test file open, and I right-click in the gutter and select "Debug 'the test name'" from the menu:

I have breakpoints in the test file, and I also have breakpoints set in my application source code.  WebStorm will stop at the breakpoints that are in the test file itself, and a *few* of the breakpoints in source files, but not all.  The breakpoints have checkmarks.

I will attach a video of this happening - Upload id: 2020_09_09_YVdibHQvMVpuC8ra (file: webstorm_not_stopping.mp4)

I have stopped and restarted WebStorm, rebooted, and upgraded Webstorm to 2020.2.1 (from 2020.2.0) today, and nothing has affected the situation.




please check your jest.config.js - what does it look like? Do you have collectCoverage enabled in it?
If the source file is instrumented for coverage, the generated code can't be correctly mapped to source; it's a well known limitation


We don't have collectCoverage enabled, and I'm not running "with Coverage" (I'm debugging).  We did have collectCoverageFrom defined for jest in package.json, but taking that out didn't help matters.


This is crippling my productivity.  No ideas?


Could you share a project the issue can be repeated with?


Can't really share our web application development project, unfortunately, and we don't really have the resources to invest in trying to develop a standalone project that reproduces the problem.  My colleagues are seeing the same behavior.  I'd be happy to record videos or have screen-sharing sessions if that would help.  I'm happy to answer any questions you might have about how our project is set up.

Here is another clue that might help you?  Suppose you have a function with several breakpoints in it that WebStorm is not hitting.  If you can find a way to step into that function, and hit Go, those breakpoints are still not hit.  Howeverif, after you step into the function, you delete and recreate the breakpoints in the function, they will get hit if you hit Go.

My colleague suspects this issue has something to do with "jest utilizing babel", in case that helps. 


This can indeed be related to babel (namely, to sourcemaps it generates) - if they are not accurate enough, certain lines of code would not be mapped correctly and not resolved while debugging. But I can't tell for sure unless I have a project to play with


After one year I'm still facing this problem, im running Jest with NestJS and sometimes the breakpoint works, sometimes it doesnt. Almost going back to VSCode, work without debug in Jest is terrible.


Hmm... do you mean that debugging work in VSCode? this can be a bug in Webstorm then, the project the issue can be reproduced with would be helpful


Closing in on two years since reporting this problem, and there has been no progress.  This will be the reason my team stops using WebStorm.

Let me describe what happens more completely, since I've experienced the problem so many times I have it memorized.

1. I start debugging my node.js application in WebStorm.  It connects to the debugger successfully and hits breakpoints just fine. This might happen 3, 4 or 5 times.

2. Then, at some point, when I start debugging my node.js application, the debugger connects successfully, but when I get to a point where a breakpoint should be hit, the breakpoint does not *appear* to have been hit, but the application I am debugging does not progress either.  It is as though the breakpoint has actually been hit internally, but the WebStorm UI does not realize it.

3. If, at that point, I stop the debugger and try to start debugging again, the debugger will fail to connect.  No matter how many times I stop debugging and start again, the debugger will "fail to connect after timeout" until I kill WebStorm and start it up again.  Then, I go back to step 1 above, rinse and repeat.

I can't send you my project and all of its proprietary source code.  You're going to have to develop a reproducible case, or send a developer to where I work and you can see it happen.



Sometimes, like just now, the number of times it succeeds in step 1 after restarting WebStorm is 0. 



I will say this:  In a half-day of anecdotal attempting to debug my application, the debugger seems to go out to lunch a lot less if I am running a single instance of my application, rather than running it in cluster mode, which these days launches like 12-16 instances.  I'm not saying it never exhibits the problem, because a second node.js application that *can't* run in cluster mode does exhibit this problem sometimes, even several times today.


Any progress on this?

This is a decision-making bug.

It works flawlessly in vscode …



As the person who entered this issue, I can say that it's been quite a while since I have experienced it.  I'm currently using version 2023.3.


First bug: The debugger picks the wrong file to break into.

I have many apps in my repo, so many main.ts, so many bootstrapApp functions. I put a break-point on one of them and it randomly picks the wrong one.

Second bug: A break-point in a file outside the folder structure of the app doesn't get hit

I put a console.log statement to check if it gets executed and it did.

Note 1: Using Rider IDE the 1st bug is the same, but not the second one!

Note 2: WebStorm 2023.3.3, Rider 2023.3.3

Note 3: No problem using vscode

EDIT 1: I don't know why but now the bug is present also using Rider …

  1. Unfortunately I failed to reproduce the issue. We had similar problems reported before, but they all seem to be fixed now. Do you have a sample project you can share where we could reproduce it? It can be a dummy app with the structure and build configurations similar to yours.
  2. Is this file included in project (as additional content root,etc.)? Debugging, just as other advanced IDE features, aren't supposed to work for files external to project (i.e. not included in it).

Hi Elena Pogorelova

I've just stumbled on this thread and I'm facing the same issue as Eric Hill.

Fortunately I'm working on an open source project so can give you something to reproduce it with. 


To reproduce:

- Clone the repo

- Install dependencies (yarn/npm)

- Set two breakpoints:

1. https://github.com/vck3000/ProAvalon/blob/f73b213e48a8bf8f5c34d9ee7beddbcebea2d757/src/gameplay/tests/game.test.ts#L159

2. https://github.com/vck3000/ProAvalon/blob/f73b213e48a8bf8f5c34d9ee7beddbcebea2d757/src/gameplay/game.ts#L678 

- Debug all jest tests


Breakpoint 1 is hit as expected, however breakpoint 2 does not get hit. 

However, if you breakpoint at 1, and step into gameMove(), you'll see it enters that function/stack appropriately. After you enter that function, if you refresh (i.e. unset and then reset) breakpoint 2 and then “continue” the debug run, Webstorm will appropriately breakpoint, as Eric Hill reported. Additionally, if you debug it from the start again, breakpoint at 1, and then manually go unset and reset breakpoint 2, it'll break appropriately. 

I've just tested with VSCode and breakpoint 2 is hit as expected. 

I also have a friend running Webstorm on Windows and he has experienced the same thing. I'm running Webstorm on Mac with Webstorm version 2023.3.4 with Node v18.14.2. 

Thank you for providing all the details, I've successfully replicated the issue.

I've updated the https://youtrack.jetbrains.com/issue/WEB-51788/Debugger-does-not-hit-source-code-breakpoint-Jest-Typescript accordingly, please follow it for updates.

Thank you Elena Pogorelova. Glad to hear you were able to reproduce the issue.