Debugger Won't hit breakpoints in jest test

[jacksaunders]

When running Jest tests, I am unable to set breakpoints in the *.test.js / *.spec.js files. When i set a breakpoint in a location and start the launch.json config the breakpoints move around.

I am unable to provide access to my repo so i have created a repo which is close to what i am working on, its an ejected create react app and can be seen here.

https://github.com/jacksaunders/vscode-jest-test

I ran vscode with all extensions disabled, and just ran the basic App test that comes with create react app.

here is a quick gif of what is happening

vscode version info

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Debugger doesn't hit breakpoints when running Jest tests (#59056)

[roblourens]

In your webpack config, could you try changing devtool to source-map? The other modes sometimes don't provide enough info for accurate sourcemapping.

[roblourens]

Actually there is some discussion going on about the same issue in facebook/create-react-app#5319

[roblourens]

I am going to keep this issue open to figure out a better workaround on vscode's end.

Pasting my response from the other issue:

---

tl;dr: a workaround is that breakpoints set after launching work.

I can repro this, I tried downgrading jest in the test repo, but it doesn't make a difference for me? Could one of you share a test repo where it does work with jest downgraded? Or if it's easier just set "trace": true in your launch config, run it again, and share the log file.

Here's the problem: In a transpiling scenario you can use the outFiles parameter to point vscode towards the output sourcemaps so it can preload them and resolve your breakpoints to their real locations. But in this scenario, the sourcemaps are generated in memory and don't exist on disk.

So you set a breakpoint in a .js file. VS Code doesn't know whether it's a bp in a script with no sourcemaps, or a transpiled script that will have sourcemaps at runtime. Since it's a .js file, we guess and set breakpoints for that path and line. Anyone using .ts or something else won't see an issue.

Then, jest loads the transpiled script and gives it the same path as the file on disk. It's a match, and your breakpoint hits. But the line numbers don't match between the two scripts, so you've stopped on the wrong line. At the same time, vscode has loaded the sourcemap so any breakpoints you set at this point will bind correctly.

If this is really new in Jest then they might have changed how they name the loaded scripts. If they can name them differently from the source files on disk, that would fix this. Maybe we should provide an option to disable this optimistic bp placement but it should "just work"...

But this scenario where sourcemaps can't be preloaded from disk has always been imperfect in vscode. We would still have a race to load the sourcemap and set the BP before the line of code with the BP executes. Chrome gives us a way to break every time a script loads, giving us a chance to catch up and load sourcemaps. Node doesn't support that unfortunately. We've experimented with guessing the name of the script at runtime, setting a BP for line 1, then checking whether it has sourcemaps. That would help in this scenario but is complex and relies on the name of the script at runtime matching the path on disk.

---

One possibility is that we adapt "breakOnLoad": "regex" from chrome-debug to help with this scenario.

[SimenB]

Hey, Jest maintainer here 👋 We do write the source map to disk (as well as keep it inline in the sourcecode of the file, https://github.com/facebook/jest/blob/714cb516944c74a9ed9d6eda867911b398003468/packages/jest-runtime/src/script_transformer.js#L272). I'm not sure if it's possible to tell vs code where it is, though?

[roblourens]

Oh that's interesting, where is that path?

[SimenB]

It is in /tmp somewhere (or your OS-dependent version of it). We get it by doing this and appending .map: https://github.com/facebook/jest/blob/714cb516944c74a9ed9d6eda867911b398003468/packages/jest-runtime/src/script_transformer.js#L109-L132
We do that for every single file transpiled by Jest.

We write it to disk for caching purposes, but maybe you can use it?

Is this something https://github.com/jest-community/vscode-jest can help solve?

[hbenl]

@roblourens I would very much like to have breakOnLoad for node debugging. I'm currently facing an issue where breakpoints aren't hit when debugging mocha tests in a docker container. When I insert a debugger; statement in the test, the debugger breaks at that statement and after that, breakpoints start working - so I guess this is the same timing issue that breakOnLoad was designed to fix.