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

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.  However, if, 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. 

https://github.com/vck3000/ProAvalon 

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 Elena Pogorelova. Glad to hear you were able to reproduce the issue. 

I am now seeing this as well - this is super annoying and a complete blocker. Reverting to VSCode for debugging.

Hi, I experienced the same issue, but only on Windows when using WSL. When debugging tests on Linux it stops on breakpoints inside the source files just fine. I have tested this with 2 projects (renovate as mentioned in this report and a private one) and for both it behaves the same.

Is the issue specific to some platforms only or just more common on some? I have never experienced this issue on Linux.

Hey folks. I just had this issue and tried the advice in the above YT ticket:

I added a breakpoint into the test code as well as in the code that was being tested, and all the breakpoints started working.

(I can't speak for how widely that will work.)

I'll post a simple solution since I came here while I was having trouble while debugging a TypeScript app.

Webstorm IDE needs tsconfig to have sourceMap: true or it won't be able to stop at any breakpoint. Such is the nature of typescript.