Jest: Debugging in Visual Studio Code does not work unless you use --legacy-bundling

[jbsulli]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?

Jest debugging in Visual Studio Code does not work unless you use npm install --legacy-bundling.

This was a fun one to track down. I was not able to get Jest to debug properly to work on my primary laptop and, after several hours of mucking with it, I tried my second laptop. It worked! After comparing differences, I noticed npm was way out of date and ultimately I discovered the hack below.

If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.

1. Download VSCode and install.
2. Clone my debug-jest-in-vscode repo. It's simply the getting started example but with my VSCode launch config.
3. Use npm install, put a breakpoint on __tests__/sum-test.js:2, and run.

What I see is, even though I have the sum-test.js file open, a new tab labeled c:\github\debug-jest-in-vscode\__tests__\sum-test.js is opened (note: I cloned to C:\github\debug-jest-in-vscode). If you hover over the tab, the full path it shows is \1000\c:\github\debug-jest-in-vscode\__tests__\sum-test.js. Also, my code is wrapped with ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){ + }});. The breakpoint is still respected and the program stops in the correct spot; however, neither placing new breakpoints nor editing code in the mystery tab seems to work.

Now, to get it to work:

1. Delete the node_modules folder entirely.
2. Use npm install --legacy-bundling, put a breakpoint on __tests__/sum-test.js:2, and run.

Now everything works as expected. Breakpoints cause my program to pause in the original source file, the source file is the same, and I can edit the source file while paused.

What is the expected behavior?

I would expect npm install's --legacy-bundling not to be needed.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

Jest: 18.1.0
Node: 4.6.0
NPM: 4.2.0
OS: Windows 10 Home (Windows_NT ia32 10.0.14393)

Note: I created an issue for VSCode team as well to hopefully get some dialog going.

[thymikee]

Maybe you'll find this thread interesting? https://github.com/facebook/jest/issues/1652

[thymikee]

Also cc: @orta

[jbsulli]

Unfortunately, his config doesn't work at all for me:

```node --debug-brk ./node_modules/.bin/jest -i
Debugger listening on port 5858
c:githubdebug-jest-in-vscodenode_modules.binjest:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\,/,g')")
^^^^^^^

SyntaxError: missing ) after argument list
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.runMain [as _onTimeout] (module.js:441:10)
at Timer.listOnTimeout (timers.js:92:15)

I have a feeling that it is because I am working from a Windows machine. I had to switch the second `runtimeArgs` value to `/node_modules/jest/bin/jest.js` to get it to run (and got the same result... I have to do `npm install --legacy-bundling`). 

I believe that our configs are largely the same but written in different ways. For example, `"stopOnEntry":true` just calls node with the `--debug-brk` flag and setting the `program` property sets what he has as his second argument. In other words, I'm just using VSCode's shortcuts and letting it handle things. So the differences are I use "--runInBand" vs "-i", I tell node "--nolazy" and use the "development" environment, and I let VSCode determine the port to use. But the `--legacy-bundling` bug is still present.

At this point, I have it working with:

    {
        "type": "node",
        "request": "launch",
        "name": "Debug Jest",
        "program": "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "args": ["--runInBand"],
        "cwd": "${workspaceRoot}",
        "runtimeArgs": [ "--nolazy" ],
        "env": { "NODE_ENV": "development" }
    }

```

What I am concerned about is that Jest functions differently with --legacy-bundling vs not. Most NPM users are not going to think to use --legacy-bundling. I ran across this fix by accident. Are you mainly focused on using Yarn and does it default to not flat? I'll reach out to the NPM team and see if there is a way to determine what the causes the difference.

[jbsulli]

Just did some more playing and found that using npm install --global-style works as well.

[orta]

Interesting, have you tried yarn too?

[jbsulli]

I hadn't before, but yes the issue appears when using yarn as well.

I'm still blown away that --global-style made a difference. With only one dependency, it doesn't seem like there would be much of a difference between having Jest's deps in a child folder vs a sibling folder.

I think I'm going to try a different version of Node and see if that changes things. I use 4 because I've been doing a lot of AWS Lambda stuff and they're still stuck on 4 for now. I would expect this to change to 6 soon as LTS for 4 changes to maintenance in April.

[jbsulli]

Found it!

I contacted NPM and they told me to try moving the module folders one by one and see if I could track down what module was causing the issue. I wrote a program to do this for me and narrowed it down to babel-jest inside of jest-runtime. Now, it works with --legacy-bundling so I had to assume another module was picking it up and changing things as a result. After searching all modules for "babel-jest", only one file had it: jest-config in build/normalize.js.

Now that I had the potential source, I removed the node_modules folder, did npm install the normal way, and confirmed the problem still exists. After several tests, I found that changing line 279 to if(false) fixed everything. So, for whatever reason, setting config.transform to { '^.+\.jsx?$': 'babel-jest' } breaks debugging in VSCode.

This only happens when using npm install without --legacy-bundling or --global-style because normalize.js is doing a weird check for installed modules and finds babel-jest. With the flags, babel-jest is nested in a way that normalize.js cannot find it.

So, anyway... the problem seems to start here.

[thymikee]

This is actually expected behaviour for Jest. That's why we advise to install babel-jest next to jest itself when working with Babel, because we support Node 4, which ships with npm 2 resolving dependencies this way. This is not needed in npm 3 and 4 or Yarn, because they flatten dependencies.

Maybe we could warn better about this?

[jbsulli]

But what you are proposing will break it. I AM using NPM 4 and the expected behavior leads to breakpoints and debugging being broken in VSCode.

[thymikee]

So you include jest and babel-jest as "devDependencies" and it doesn't work? I only see jest in your repo.

[jbsulli]

I tried doing exactly as you say just to double check. Yes, it's still broken. What you are proposing will force it to always be broken. Consistency, yes... but not the desired outcome.

What I've been saying all along is that by NOT flattening, VSCode's debugger will work without issue. Flattening breaks things.

[jbsulli]

Any thoughts?

[cpojer]

@orta can you advise on the next steps here? Anything we need to do?

[orta]

I'm not sure there's anything we can do here TBH, other than recommend people update node if they're having this specific issue.

[clintjhill]

For anyone interested - I think I have a simple fix for this. I commented on the VS Code issue here: https://github.com/Microsoft/vscode/issues/19566#issuecomment-301254539