Vscode: Breakpoints not hit when debugging jest with inspector

Created on 4 Jun 2017  路  25Comments  路  Source: microsoft/vscode

  • VSCode Version: 1.12.2
  • OS Version: Win 10

I had existing nodejs project setup with debug launch configuration as below:

        {
            "type": "node",
            "request": "launch",
            "name": "Jest Tests",
            "program": "${workspaceRoot}\\node_modules\\jest\\bin\\jest.js",
            "args": [
                "-i"
            ],
            "preLaunchTask": "build",
            "sourceMaps": true,
            "internalConsoleOptions": "openOnSessionStart",
            "outFiles": [
                "${workspaceRoot}/dist/**/*"
            ],
            "envFile": "${workspaceRoot}/.env"
        }

When I debug with node 6.10.3 the latest LTS version which is recommend for VScode the debugging works correctly. Output command generated by vscode shown below:

Debugging with legacy protocol because Node.js v6.10.3 was detected.
node --debug-brk=31454 --nolazy node_modules\jest\bin\jest.js -i

However, I updated to node 8 and ran the same launch configuration and stopped hitting the breakpoints. Output of command generated:

Debugging with inspector protocol because Node.js v8.0.0 was detected.
node --inspect=11120 --debug-brk node_modules\jest\bin\jest.js -i 
Debugger listening on ws://127.0.0.1:11120/5bc05720-def6-451b-8658-fe128d2ea624
For help see https://nodejs.org/en/docs/inspector
(node:7960) [DEP0062] DeprecationWarning: `node --inspect --debug-brk` is deprecated. Please use `node --inspect-brk` instead.
(node:7960) [DEP0062] DeprecationWarning: `node --inspect --debug-brk` is deprecated. Please use `node --inspect-brk` instead.

My debug configuration is a little unconventional/more complex than normal use case since i'm using VScode debugger to invoke jest library which then dynamically loads test files as opposed to the more normal scenario of directly targeting the entry point to server startup or library file.

I think it would be nice to start with smaller project to see if I could reproduce but this is in a simpler scenario without Jest involved but this is the info i have now.

bug debug upstream

Most helpful comment

I was unable to use breakpoints with a launch configuration similar to @mattmazzola's under Node 8.3.0, and upgrading to Node 8.4.0 (and Code 1.15.1) fixed this issue for me. So I believe this is now resolved upstream.

All 25 comments

Tagging @weinand since he was helping me out in the Gitter chat.

Can you try debugging with Node 6.10, and "protocol": "inspector" in your launch config and tell me whether that works?

Using "protocol": "inspector" with node 6.10.3 did not work and was actually worse. It did not hit breakpoints, but also it appears that it is not even executing jest. I don't see any test results output when using that protocol.

Command that was generated:

node --inspect=27933 --debug-brk node_modules\jest\bin\jest.js -i 
Debugger listening on port 27933.
Warning: This is an experimental feature and could change at any time.

Hm, I haven't used jest before. Is this a project that I can try out?

Yea, it's an open source project: https://facebook.github.io/jest/

I think it was internal at Facebook for a while, and they did some major updates a few months back to make it more easily consumable publicly and it's quickly becoming standard for testing. It basically combines and improves all the best features of the existing frameworks like jasmine, mocha, etc... such as having async support for all methods, and built in coverage reporting which were usually add-ons to others. I think they use jasmine internally use for the assertions, mocking and stuff but add some other helper syntax to make things little more friendly.

The jest docs recommend a different approach which uses chrome, but the work flow is really poor and I wanted to do it in VScode.
I created video demonstrating: https://www.youtube.com/watch?v=OSA1t3y3Mns&lc=z122wrno3pvydrzmd22lvbnggza5cdruq and this pattern was working for node 6 and stopped working with node 8.

It seems like either this is a non-issue (debugging actually works fine with node 8 but my particular combination of launch config and jest config is causing problems) or maybe issue of VScode debugger not properly attaching to node debugger.

If there is alternate more appropriate way to test using jest with vscode I will try it. This was just the most straight forward solution I could think of. All TypeScript is built and output to dist folder, jest is configured to look at files in dist folder, debugger invokes jest in interactive (sequential) mode

I actually meant, can I try your jest project, in case there's some problem specific to your particular project?

Yea, project i was playing on was here: https://github.com/mattmazzola/interview-questions

Trying it, I can't get it to work with chrome devtools either. The -i flag would be necessary, but it's like it doesn't work because I don't even hit 'debugger' statements in code.

Seems like there are other issues too? https://github.com/Microsoft/vscode/issues/19566#issuecomment-301254539

I see the official guidance for debugging which uses the legacy debug protocol in node (via --debug), but Node 8 doesn't have that protocol. So I wonder what the official recommendation is for debugging jest in Node 8.

FYI, If you look inside the comments of reference issues in Jest library they closed this saying it is issue with Node:
https://github.com/nodejs/node/issues/7593

Given that new information, it seems this is confirms to not be an issue with VSCode, and also not an issue with Jest, but a limitation of node debugging when using the special vm context stuff. This issue can be closed

@mattmazzola thanks for the upstream issue.

set "type": "node", will fix this issue

@roblourens I just fixed my Jest debugging setup nightmare by downgrading Node 8 to 7.10.1 as there appear to be issues with the inspector protocol like you mentioned. Details on SO:

Can do some real work now, and getting nice debugger experience that I remember from old .NET days :)

@aschrijver Does not work for me either

@ds82 My previous comment appears wrong. I am still in debugging setup hell. VS Code probably working properly. But now it focuses on Jest: https://github.com/facebook/jest/issues/4028#issuecomment-315273833 and its use in Ignite CLI: https://github.com/infinitered/ignite/issues/1107
Oh..and this one: https://github.com/Microsoft/vscode/issues/26782
I'll update SO and issues with my findings.

[UPDATE: Updated stackoverflow, see links above. Status: Not going to use Jest, still having issue https://github.com/Microsoft/vscode/issues/26782 , annoying but not blocking]

same as @aschrijver, forced to downgrade Node 8 to 7.10.1 to be able to debug my jest tests.

Same issue, downgrade Node 8 to 7.10.1 make Jest debug work.

I was unable to use breakpoints with a launch configuration similar to @mattmazzola's under Node 8.3.0, and upgrading to Node 8.4.0 (and Code 1.15.1) fixed this issue for me. So I believe this is now resolved upstream.

I had the same issue (downgraded to 7.10.1 -- got it working on 7.10.1 but required pre-compiling ts -> js and using a custom jest config that targeted the pre-compiled js when debugging.

Its now working for me on node/8.5.0 while using runtime compilation with ts-jest. Magic!

I am seeing an issue still though -- there is no console output in the debug console (or anywhere else) -- makes it hard to see whether the test case actually passes/fails.

Is this a bug or expected behavior? Is there a way to see console output while debugging?

@breathe, you can try adding "console": "integratedTerminal" to your launch.json configuration. This has enabled me to get console output when debugging Jest tests.

Thanks @Cheerazar! "console" : "integratedTerminal" works for me for this. Its not at all clear to me as a user why the debugger console configuration's exist as they do ... It would be great if vscode could motivate the reasoning behind these options to help users understand why they exist/when they might be needed ... I guess its useful sometimes to unclutter the debugger output stream? Seems like it would be nice to have the console output from the debugged program available _somewhere_ in the ui though even if you didn't want it in the debug console ...

I was running with Node 8.1.4 and it wasn't working. With Node 8.6.0, I can debug.

I have found two different launch.json configuration to make it works with VsCode

    {
            "type": "node",
            "request": "launch",
            "name": "Jest 1",
            "program": "${workspaceRoot}/node_modules/jest/bin/jest",
            "args": [
                "-i"
            ],
            "preLaunchTask": "tsc: build - tsconfig.json",
            "internalConsoleOptions": "openOnSessionStart",
            "console": "integratedTerminal",
            "outFiles": [
                "${workspaceRoot}/build/dist/**/*"
            ],
            "envFile": "${workspaceRoot}/.env"
        }

and

     {
            "name": "Jest 2",
            "type": "node",
            "request": "launch",
            "program": "${workspaceRoot}/node_modules/jest-cli/bin/jest.js",
            "stopOnEntry": false,
            "args": [
                "--runInBand"
            ],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": null,
            "runtimeExecutable": null,
            "runtimeArgs": [
                "--nolazy"
            ],
            "env": {
                "NODE_ENV": "test"
            },
            "console": "integratedTerminal",
            "sourceMaps": true
        }

I am hitting breakpoints in my Jest spec with this configuration, however, I am not able to hit break points in the imported source. Any ideas why that might be the case? Thanks.

@pebanfield I'm seeing similar behavior.

I noticed an error on the breakpoint. It says "Breakpoint ignored because generated code not found (source map problem?).

I am using babel-jest. My understanding what that babel-jest should be generating the source maps? I am also generating source maps via a webpack build, but these should not really be involved. It's not clear how I can correct this in the VS Code configuration? Where do I see where to set the path? And is there a way to see what path is incorrect so that I can have a chance of fixing it?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sirius1024 picture sirius1024  路  3Comments

trstringer picture trstringer  路  3Comments

chrisdias picture chrisdias  路  3Comments

philipgiuliani picture philipgiuliani  路  3Comments

vsccarl picture vsccarl  路  3Comments