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

[nolazybits]

🐛 Bug Report

node --inspect-brk jest --runInBand --watch
doesn't stop on breakpoints or debugger statement whereas
node --inspect-brk jest --runInBand
will (no --watch flag)

Noe: It is using ts-jest 23.0.0

jest.config.js

module.exports = {
    globals: {
        "ts-jest": {
            skipBabel: true,
            enableTsDiagnostics: true,
            disableSourceMapSupport: true
        }
    },
    roots: [
        "<rootDir>/src",
        "<rootDir>/tests"
    ],
    transform: {
        "^.+\\.tsx?$": "ts-jest"
    },
    testRegex: "(/tests/.*.(test|spec)).ts$",
    moduleFileExtensions: [
        "js",
        "ts",
        "json",
        "node"
    ],
    setupTestFrameworkScriptFile: "jest-extended",
    verbose: true
};

Expected behavior

I would expect debugging to work with --watch

Run npx envinfo --preset jest

it errors with

(node:2536) UnhandledPromiseRejectionWarning: TypeError: Cannot read property '1' of null

node --version
v10.0.0

jest version
23.4.0

Thanks

[phnah]

I'm having a similar problem.

Node: v8.9.0
jest: v23.4.0

[jamietre]

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

[mgibson91]

@jamietre Thanks! The latest packages weren't working for me but that combination does! For the sake of any others, here is my config:

Packages

• jest: 22.4.4
• ts-jest: 22.4.6
• node: 9.2.0

Webstorm steps

• Add new Jest config
• Add Compile Typescript step (not sure if this is neccessary as when I removed it, still worked but could be cache related)

jest.config.js

module.exports = {
  transform: {
    "\^.*ts$": "ts-jest",
  },
  testMatch: [
    '<rootDir>/test/*.spec.ts',
    '<rootDir>/test/**/*.spec.ts',
  ],
  moduleFileExtensions: [
    "ts",
    "js",
    "json",
  ],
  moduleNameMapper: {
    "@/(.*)$": "<rootDir>/$1",
    "^src/(.*)$": "<rootDir>/src/$1",
    "^core/(.*)$": "<rootDir>/src/core/src/$1",
  },
  testEnvironment: 'node',
};

[jamietre]

@mgibson91 I ended up at Jest 23.1.0. There are some behavior changes between 22.4.4 and 23.1.0 (bug fixes perhaps?) related to mock resolution when writing typescript mocks for javascript files, which we had explicit tests for because it was confusing.

So that may not matter to you but just wanted to let you know everything works at least up to 23.1.0 (with ts-jest 22.4.6) for us.

[mgibson91]

@jamietre Good to know, thanks!

[jamietre]

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.

[larrybotha]

thanks @mgibson91, the versions you provided work for me:

"jest": "22.4.4",
"ts-jest": "22.4.6"
node: v9.5.0

running the following command:

$ node --inspect $(npm bin)/jest --watch

Breakpoints were not being hit when using jest@23.4.1

[sokra]

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

[ranyitz]

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?

[geekox86]

Hi awesome Jest team,

Thank you for your wonderful efforts to make our coding workflows better.

I unfortunately suffer from the same issue with the following versions:

jest 23.5.0
ts-jest 23.1.3
typescript 3.0.1
node 10.7.0

Here is my jest.config.json:

{
  "collectCoverage": true,
  "coverageReporters": ["text"],
  "moduleFileExtensions": ["js", "jsx", "ts", "tsx"],
  "testEnvironment": "node",
  "testMatch": ["**/?(*.)test.ts?(x)"],
  "transform": { "\\.tsx?$": "ts-jest" }
}

And this is my script to run tests:

node --nolazy --inspect-brk ./node_modules/.bin/jest --runInBand --no-cache --watch

Breakpoints only hit and stop if I have a single test file. However, with multiple test files, no breakpoint is respected, including using debugger keyword.

Any clue is appreciated.

Thank you!

[thymikee]

If you're in --watch mode and having more than 1 test, Jest will spawn a worker, which supposedly doesn't work with debugger currently. Removing --watch flag will let you debug tests normally.

[jamietre]

@sokra

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.

@thymikee

If you're in --watch mode and having more than 1 test, Jest will spawn a worker, which supposedly doesn't work with debugger currently. Removing --watch flag will let you debug tests normally.

Jest definitely doesn't disable runInBand always in watch mode, per @sokra comment, since this is pretty much the only way I've ever used debugging with Jest (in watch mode). Maybe it disables it with more than 1 test, but I've probably never tried to do this intentionally. Usually when debugging, it's dealing with a specific test.

My problem was always when running just one test, and I was able to fix it only by disabling the cache. I am guessing there are more things at play here then just runInBand + watch.

In any event, this certainly seems to be involved somehow. EIther way I think Jest should fail if someone tries to use incompatible options instead of just "blacklisting" it, resulting in very confusing outcomes.

[geekox86]

Thank you guys for your prompt answers.

Just being digressive here, how does your debugging workflow with Jest look like then? Do you switch back and forth between Jest output and manual CLI to debug failed ones one by one? How can this be more effective?

Thank you again for your help!

[jamietre]

Do you switch back and forth between Jest output and manual CLI to debug failed ones one by one? How can this be more effective?

It's not typical for me to have more than a single test that needs debugging at one time; having Jest debugging only work for one test doesn't seem like that big a deal to me (if indeed that's the only problem here). That is - I wouldn't usually start work on a new test while an existing one was broken. If I happened to have some regression that broke lots of things, I'd just pick one to deal with, and fixing the underlying issue would likely fix them all.

The bigger issue (for me anyway) is that it's been very confusing to understand why it wasn't working and get it to work reliably.