3

I created a React Native project using the popular Ignite CLI v2.0.0 with the default boilerplate. Then I adorned it with a bunch of nodejs shims, because I'll have some node-based dependencies. Everything is working and I can run the Jest tests from the command line. So far, so good.

However, now one of my unit tests is timing out. This is probably due to an async call failing that invokes a mocked out node function. But there is no information on error, location, etc.

So I want to debug using Visual Studio Code v1.13.1 and here problem starts. I can't for the life of me figure out how to configure this so I can set breakpoints both in the tests as in the app code + node_modules.

I have installed the React Native Tools v0.3.2 and can start the debugger using the default Debug Android configuration:

[vscode-react-native] Finished executing: adb -s emulator-5554 shell am broadcast -a "com.myexample.RELOAD_APP_ACTION" --ez jsproxy true
[vscode-react-native] Starting debugger app worker.
[vscode-react-native] Established a connection with the Proxy (Packager) to the React Native application
[vscode-react-native] Debugger worker loaded runtime on port 13746
Running application "MyApplication" with appParams: {"rootTag":1}. __DEV__ === true, development-level warning are ON, performance optimizations are OFF

But no breakpoints are hit. VS says: Breakpoint ignored because generated code not found (source map problem?). (btw: both index.android.bundle and index.android.map have just been generated in .vscode/.react). And also I don't see a way to debug through the test code (which lives in ${projectRoot}/Tests).

Based on much googling I created another debug configuration for running Jest in VS Code:

    {
        "type": "node",
        "request": "launch",
        "name": "Jest Tests",
        "program": "${workspaceRoot}/node_modules/jest-cli/bin/jest.js",
        "args": [
            "--config",
            "package.json",
            "--runInBand",
            "--verbose",
            "--no-cache",
            "-u"
        ],
        "runtimeArgs": [
            "--nolazy"
        ],
        "console": "internalConsole",
        "sourceMaps": true,
        "address": "localhost",
        "port": 8081,
        "outFiles": [
            "${workspaceRoot}/.vscode/.react"
        ],
        "env": {
            "NODE_ENV": "test"
        }
    }

This at least runs the tests, showing test report in the VS debug console, but once again no breakpoint anywhere gets hit.

I also tried setting outFiles to the location where ignite generates the bundle, i.e. ${workspaceRoot}/android/app/build/intermediates/assets/debug/* with same results.

Can anyone please point me in the right direction?

PS. I am on Ubuntu 16.04:

System
  platform           linux                                                                                                
  arch               x64                                                                                                  
  cpu                4 cores      Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz  

JavaScript
  node               8.1.2        /usr/local/bin/node  
  npm                4.6.1        /usr/local/bin/npm   
  yarn               0.24.6       /usr/bin/yarn

React Native
  react-native-cli   2.0.1       
  app rn version     0.45.1      

Ignite
  ignite             2.0.0        /usr/local/bin/ignite  

Android
  java               1.8.0_111    /usr/bin/java  
  android home       -            undefined
Arnold Schrijver
  • 3,588
  • 3
  • 36
  • 65
  • Okay, it's a nightmare! I ditched the VS Code debugger. Couldn't get it to recognize any breakpoint. Now looking for Chrome debugger. Looks promising with just `node --inspect-brk node_modules/.bin/jest --verbose --no-cache --runInBand` on the command line and Node Inspector Manager picking up in Chrome. But...this bumped into another blocker: [v8_inspector: Support the V8 debugger from within VM contexts (Github NodeJS issue #7593)](https://github.com/nodejs/node/issues/7593). Seems no Chrome debugging for now... – Arnold Schrijver Jul 12 '17 at 21:39

1 Answers1

3

Finally found the solution. It seems there are still a number of issues with the new inspector protocol in Node 8.*. In short the support for --inspect is still quite experimental.

For example the NodeJS Inspector Manager (NiM 0.13.8) was crashing and disconnecting websocket after few second (See: NiM Github issue #17 and Chromium bug #734615).

So I downgraded NodeJS 8.1.2 --> 7.10.1

Now finally things work as expected. I can do all debugging in VS code, hit all the breakpoints, with the following debug configuration:

    {
        "type": "node",
        "request": "launch",
        "name": "Launch Tests",
        "program": "${workspaceRoot}/node_modules/.bin/jest",
        "args": [
            "--runInBand",
            "--no-cache"
        ],
        "runtimeArgs": [
            "--debug-brk=127.0.0.1:5858"
        ],
        "port": 5858
    }

Wasted more than a day on something that should be a 5 min. no-brainer. But luckily its working now!

Arnold Schrijver
  • 3,588
  • 3
  • 36
  • 65
  • It seems there is still no cigar. Apparently this runs code direct from disk using Node native objects, instead of using the source map and using browserified shims. Investigating.. – Arnold Schrijver Jul 13 '17 at 11:04
  • Well, my answer probably addresses most cases, but unfortunately not mine. This because Jest runs tests from disk, not transpiled bundle with shims in place. Jest team states: `"This is the expected behavior. Jest is supposed to run on source files. On any large codebase, generating a bundle before running tests is too slow, so Jest compiles files just-in-time, which makes it fast."`. Though probably a miscommunication I'm going for Jasmine, Mocha and/or Karma. If you have problems I invite you to improve the answer by following up on: https://github.com/facebook/jest/issues/4028 – Arnold Schrijver Jul 15 '17 at 16:20
  • **Update**: more info from Jest team: `general way Jest handles this is by doing the transpilation itself. So you set up transformers in your config that Jest itself uses to do the transpilation. See https://facebook.github.io/jest/docs/configuration.html#transform-object-string-string An example config for Typescript is here to give you an idea of what this could look like: https://github.com/kulshekhar/ts-jest` – Arnold Schrijver Jul 17 '17 at 15:48
  • The issues seems to have been resolved as of Node 8.4.0. I'm using VSCode 1.15.0 and Jest 20.0.4 and test debugging is working fine. – George Sapkin Aug 16 '17 at 15:59
  • I'm using VSCode 1.22.3, Node 8.4.0 and jest 22.4.6 and I still get that issue. – SudoPlz Apr 16 '18 at 23:35