jest: `node --inspect-brk jest --runInBand --watch` doesn't stop on breakpoint or debugger statement.

I started having trouble again after downgrading to 23.1.0, and after pulling some hair out I got things to work reliably by using --no-cache when invoking Jest. This also seems to solve the problem with the latest Jest release too. It’s not clear to me why just downgrading Jest to the version that had been working reliably before didn’t work, but there are so many moving parts that have changed in last few weeks (VS Code version, typescript, jest, ts-jest) I assume there are other things involved.

I tried the following:

jest --inspect --watch

Breakpoints are unverified. Debugging doesn’t work at all

jest --clearCache
jest --inspect --watch

Breakpoints are verified. Stops on breakpoints the first run only. After changing something resulting in tests restarting, vscode still shows verified breakpoints, but the debugger doesn’t work any more.

jest --no-cache --inspect --watch

Seems to work reliably.

So there’s something wrong with the way sourcemaps are cached, apparently, and it isn’t just old/invalid cached information lying around from an older version of something, since clearing the cache only results in it working once.

Ran into this, took about 5 hours thinking my VSCode was malfunctioning. If anyone else has a workflow of running jest in watch mode, then using VSCode to “Attach by Process ID”, I recommend modifying your command line to:

jest --watch --no-cache --runInBand

I assume #6647 causes this issue.

Blacklisting “in band” mode when using the watch mode fixes the issue, since tests are executed in workers, freeing the main process.

runInBand is backlisted when watching. This also breaks debugging in watch mode for me. Removing --watch and only using --runInBand works, but slows me down, because jest startup has to paid every time, while restarting tests in watch mode is faster.

I would say always use workers in watch mode expect when passing --runInBand.

cc @mjesun

This is still an issue for in v27.0.3

After much experimentation, I was able to get TypeScript spec debugging working with VSCode and Jest v24.x.

My setup:

• NodeJS v10.15.3 (latest LTS)
• Jest v24.x
• TS-Jest v23, v24
• Latest VSCode

Launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Debug unit tests",
            "runtimeArgs": [
                "--inspect-brk",
                "--nolazy",
                "node_modules/jest/bin/jest",
                "--runInBand",
                "--watch",
                "--config=path/to/jest.config.json",
            ],
            "sourceMaps": true,
            "disableOptimisticBPs": true,
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "port": 9229,
            "env": {
                "NODE_ENV": "test"
            }
        }
    ]
}

Jest is configured with preset ts-jest/presets/js-with-ts.

TypeScript is configured with "sourceMap": true.

Note that even watch is working!

@jamietre

I’ve scaled my test back to this:

test.only("it does some shit", () => { debugger })

I’m running yarn test:debug aTest.test.js from this package.json

{
  "scripts": {
    "test": "jest --colors",
    "test:debug": "node --inspect-brk node_modules/.bin/jest --watch --no-cache --runInBand"
  },
  "jest": {
    "verbose": true,
    "collectCoverage": false,
    "collectCoverageFrom": [
      "src/**/*.{js,jsx}"
    ],
  },
  "devDependencies": {
    "@babel/cli": "^7.0.0",
    "@babel/core": "^7.2.0",
    "@babel/plugin-transform-object-assign": "^7.0.0",
    "@babel/preset-env": "^7.0.0",
    "babel-core": "^7.0.0-bridge",
    "babel-jest": "^23.6.0",
    "babel-loader": "^8.0.0",
    "jest": "^23.6.0",
    "regenerator-runtime": "^0.12.1",
    "webpack": "^4.17.1",
    "webpack-cli": "^3.1.0"
  }
}

Chrome will pause here:

(function (exports, require, module, __filename, __dirname) { 
/**
 * Copyright (c) 2014-present, Facebook, Inc. All rights reserved.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

const importLocal = require('import-local');

if (!importLocal(__filename)) {
  require('jest-cli/bin/jest');
}

});

And in my terminal stops here:

 PASS  test/request/aTest.test.js
  ✓ it does some shit (4ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.309s
Ran all test suites matching /aTest.test.js/i.

Active Filters: filename /aTest.test.js/
 › Press c to clear filters.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press o to only run tests related to changed files.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

I’m having this problem also. At first I thought it was Visual Studio Code issue; there seems to be a problem with debugging in the latest release as well which confuses things further.

But the workarounds and downgrading vscode didn’t work for me. I had to downgrade Jest to 22.4.4 to get debugging to work correctly again. This could also be a ts-jest issue, since I’ve been unable to run ts-jest@23 for different reasons.

node: v8.9.3
jest: 23.4.1
ts-jest: 22.4.6

Is this still an issues in Jest 25? We’ve had a few fixed to source map handling in the last few releases

Same, the trigger is the ‘–watch’ flag. Running without it makes breakpoints and debugger hit

how about just NODE_OPTIONS="--inspect-brk"?

Note: Use VS Code if you can! (see here) It’s way faster and less finnicky than ndb.

The ndb solution

Using ndb, we can debug child processes (so --runInBand should not be used). Breakpoints and debugger statements are respected. 😃

note: You may need to set a breakpoint before your debugger statements are respected. 😦

Directions

1. Run npm install -g ndb
2. Add "debug": "jest --watch" to your NPM scripts
3. Run ndb (no args) from your package’s root directory
4. Run the NPM script from within ndb (see here)

Cheers man

https://github.com/facebook/jest/blob/fb2a6ac4d3f4e9530941e24030b52f3d506aa2de/packages/jest-cli/src/TestScheduler.js#L88-L94

What do you say about checking process.execArgv, look for --inspect/--inspect-brk and runInBand as a result?

Do we have a reason not to runInBand while debugging?