Jest: Jest hangs on Windows Git Bash

[Prophet32j]

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

What is the current behavior?
Running Jest within Windows Git Bash. NPM will attempt to execute Jest, but then it sits and hangs without doing anything. Here is what shows after 30 minutes of waiting:

$ npm test

> [email protected] test C:\dev\ITADA\web-ui
> jest

What is the expected behavior?
I expect the tests to run.

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

Environment:
 - OS: Windows 7
 - Windows Git Bash: version 2.8
 - npm: v3.7.3
 - node: v5.9.0

package.json:
...
"jest": "^18.1.0",
"babel-jest": "^18.0.0"
},
"jest": {
    "moduleDirectories": [
      "node_modules",
      "js"
    ],
    "setupFiles": [
      "<rootDir>/test/__env__/setup.js"
    ],
    "testPathIgnorePatterns": [
      "/node_modules/",
      "/js/",
      "/src/",
      "/dist/",
      "/build/",
      "/coverage/"
    ],
    "collectCoverageFrom": [
      "js/**/*.js",
      "!**/node_modules/**",
      "!**/build/**",
      "!**/dist/**",
      "!**/coverage/**"
    ],
    "coverageDirectory": "coverage",
    "coverageReporters": [
      "json",
      "lcov",
      "text-summary",
      "html"
    ]
  }

[fcFn]

Same here. But it works very well with Yarn (yarn test).

[budnix]

I have the same problem. It hangs on when executing npm test, yarn test or directly jest.

Environment:

• OS: Windows 10 (VM)
• Git for Windows: 2.10.0.1
• npm: v3.8.6
• node: v5.12.0
• jest: 19.0.2

Config:

$ ./node_modules/.bin/cross-env BABEL_ENV=commonjs ./node_modules/.bin/jest --debug
jest version = 19.0.2
test framework = jasmine2
config = {
  "automock": false,
  "bail": false,
  "browser": false,
  "cacheDirectory": "C:\\Users\\IEUser\\AppData\\Local\\Temp\\jest",
  "clearMocks": false,
  "coveragePathIgnorePatterns": [
    "\\\\node_modules\\\\"
  ],
  "coverageReporters": [
    "json",
    "text",
    "lcov",
    "clover"
  ],
  "expand": false,
  "globals": {
    "__HOT_BUILD_DATE__": "",
    "__HOT_PACKAGE_NAME__": "",
    "__HOT_VERSION__": "",
    "__HOT_BASE_VERSION__": ""
  },
  "haste": {
    "providesModuleNodeModules": []
  },
  "moduleDirectories": [
    "node_modules"
  ],
  "moduleFileExtensions": [
    "js",
    "json",
    "jsx",
    "node"
  ],
  "moduleNameMapper": [
    [
      "^handsontable(.*)$",
      "C:\\Users\\IEUser\\handsontable\\src$1"
    ],
    [
      "^walkontable(.*)$",
      "C:\\Users\\IEUser\\handsontable\\src\\3rdparty\\walkontable\\src$1"
    ],
    [
      "\\.css$",
      "C:\\Users\\IEUser\\handsontable\\test\\__mocks__\\styleMock.js"
    ]
  ],
  "modulePathIgnorePatterns": [],
  "noStackTrace": false,
  "notify": false,
  "preset": null,
  "resetMocks": false,
  "resetModules": false,
  "roots": [
    "C:\\Users\\IEUser\\handsontable\\test\\unit",
    "C:\\Users\\IEUser\\handsontable\\src\\plugins"
  ],
  "snapshotSerializers": [],
  "testEnvironment": "jest-environment-jsdom",
  "testMatch": [],
  "testPathIgnorePatterns": [
    "C:\\\\Users\\\\IEUser\\\\handsontable\\\\node_modules\\\\",
    "C:\\\\Users\\\\IEUser\\\\handsontable\\\\test\\\\unit\\\\index.js"
  ],
  "testRegex": "(\\.spec\\.js)|(\\.unit\\.js)$",
  "testResultsProcessor": null,
  "testURL": "about:blank",
  "timers": "real",
  "transformIgnorePatterns": [
    "\\\\node_modules\\\\"
  ],
  "useStderr": false,
  "verbose": null,
  "watch": false,
  "rootDir": "C:\\Users\\IEUser\\handsontable",
  "name": "a82ab501bc3859fd81bb01d2f351c915",
  "setupFiles": [
    "C:\\Users\\IEUser\\handsontable\\node_modules\\babel-polyfill\\lib\\index.js"
  ],
  "testRunner": "C:\\Users\\IEUser\\handsontable\\node_modules\\jest-jasmine2\\build\\index.js",
  "transform": [
    [
      "^.+\\.jsx?$",
      "C:\\Users\\IEUser\\handsontable\\node_modules\\babel-jest\\build\\index.js"
    ]
  ],
  "cache": true,
  "watchman": true
}

Edit: My tests started working when it runs in the same process (with --runInBand argument)

[adammcfadden]

Same behavior here. I am using this with react-scripts triggering the tests, and otherwise default react-scripts configuration.

Setup:

• Jest: 18.1.0
• react-scripts: 0.9.3
• Node: v6.9.2
• npm: 4.4.1
• OS: Windows 10

Here is where it is working/not working for me:

• Works in git bash with yarn test
• Works in command prompt with npm test or yarn test
• Does not work in git bash with npm test
• Does not work in git bash with npm test --runInBand

The tests will sometimes run in git bash with npm test, but the interactive watch options (a to run all, q to quit, ...) do not work, and the tests must be force quit.

[cpojer]

It seems like this is not a Jest issue but rather a Windows issue? What happens if you do --no-watchman?

[alisd23]

I've got the same issue, using git bash, either through npm run, yarn run or directly running the jest global.

However adding the -i '--runInBand' option fixes this for me, not sure why.

[milanvodicka]

Same here (Windows 10, Node 6.10.3, Jest 19.0.2). I confirm, that the "-i" option fixes it for me too.

[jackhamburger]

I ran into this issue too. runInBand fixes it but is clearly suboptimal. Also using -i and --watch causes all tests to get trigger upon just a modification of a single test file. (v20.0.4)

[itsmikechu]

Thanks @alisd23 -i helped me out.

[lindesvard]

Same problem for me. Can also confirm --runInBand and -i solved it!

[brantphoto]

We're having the same problem with hanging and slow performance on Windows (node v6.10.2 and windows 10). Has anyone been able to get to the root of this problem? Is it an issue with watchman or parallel processing?

btw, @cpojer thanks so much for your work on Jest. We just transitioned over from Karma/Mocha to Jest at our company and have seen great speed improvements on our OSX machines and have had an overall great experience. Again, thanks!

cc: @mhdnp1234

[brantphoto]

update: we used -i on our team-member's Windows machine and all is working well again.

[bennett000]

@cpojer when we try --no-watchman on our Windows machines our tests just hang. Technically -i works but then our tests run in serial and our performance suffers significantly.

This is unfortunate since one of the main reasons we want to use Jest over our existing Karma suites is that Jest is significantly faster, at least on UNIX style systems.

If this is a Windows limitation we'll have to stick with Karma, which is not the end of the world but we'll be missing out on Jest's great feature set.

[cpojer]

If you want this to be fixed, figure out why it breaks and send a pull request. This is open source, not the place where you can ask me to fix problems you are running into. I'm sorry this is unfortunate to you. If Jest doesn't work for you, either fix it or don't use it.

[jackhamburger]

@cpojer In @bennett000 's defense this isn't some corner-case. This is support for the windows platform at large

[bennett000]

• I never actually asked you to fix it.
• I wanted to point out that there is a Windows limitation.
• I even pointed out that it's (mostly) irrelevant to me if you do or do not fix the issue.

I get that a lot of people demand things of OSS devs. I'm a big fan of "How to ask questions the smart way".

Sorry for the extra stress. I'll buy you a beer if I see you at a conference or something (not for fixing the issue just to help with your stress, as for the issue I love jest, and I'll find a Windows machine and dig deeper)

[bennett000]

@jackhamburger what are the details of your use case? Windows version, node version, CPU architecture, git bash version, JS or TS, and rough size of your test suite?

I know in the fail case I saw it was on a codebase with ~400 tests... I need to reach out to the dev to find out the rest of his system details but I won't get to see him until tomorrow or Monday.

I don't have a Windows machine or direct access to one but I did try a Windows 7 x86 (32 bit) VM using git bash 2.13 with both Node 8, and Node 5.12, using both yarn and npm and I didn't hit the issue. I _thought_ i hit it for a minute but stdout was being weird with yarn for some reason.

Hopefully tomorrow I can get deeper into the real world problem.

_update_

The person I wanted to meet with is AFK, possibly off today. In unrelated news I did find other weird issues with git bash in general. @jackhamburger have you ever tried running the tests in straight up CMD.exe as opposed to git bash?

_update II - July 12_

The machine in our fail case was a Windows 7 64 bit machine. I will be looking at it later today. Initial reports are that using CMD.exe as opposed to git bash have been fine. I should know more in the next few hours. If thing work using CMD.exe then I have no interest in pursuing the issue further since it's effectively "solved" for our potential use case.

[Prophet32j]

We've moved off of Windows onto Mac. Never could get it to work on git bash for me, but others on the team could get it to run.

I don't see much help for this issue as it appears to be limited solely to git bash. The tests ran just fine in CMD/Powershell.

[thinkOfaNumber]

FYI for anyone still following, it's not _just_ git bash.

For me it works in cmd but doesn't work on our build server (Bamboo). Tests just hangs without any output. I killed the process after 90 minutes (tests usually complete in about 1 minute). All other npm & node tasks seem to work fine.

--runInBand works for me in this scenario.

[ianschmitz]

We were experiencing the same hanging of Jest tests on our Visual Studio Team Services build server (jest/20.0.4 npm/3.10.10 node/v6.9.4 win32 x64).

-runInBand fixed the hanging tests for us. However this causes a significant slowdown in total test time, which is not ideal.

[bennett000]

@ianschmitz what shell program are you using to kick things off? We had some problems with git bash.

For our case the biggest problem was enterprise grade AV and encryption slowing down disk access which is obviously not a Jest issue.

[ianschmitz]

This is the command that is issued by our VSTS build server:

C:\Windows\system32\cmd.exe /D /S /C ""C:\Program Files\nodejs\npm.cmd" test -- --coverage "--testResultsProcessor=jest-junit" --runInBand".

So looks like it's using the Windows Command Shell to kick off Jest.

[matthidinger]

I was also getting random hangs while the tests ran in VSTS --runInBand fixed it.

[sebinsua]

This fixed it for us. I can't remember where I found this, but posting it here in case others need it.

alias yarn='winpty yarn.cmd' 

(We were using yarn test and this was calling jest which it somehow caused to fail.)

[seurimas]

For the npm crowd, the fix from @sebinsua also works when adjusted like so:

alias npm='winpty npm.cmd'

(For npm test that calls jest)

[Enalmada]

For anyone on windows getting jest hang, make sure you are using the latest available version (at least 22.0.6). I was playing around with some 3rd party code that had a pre-commit hook with jest and it was just hanging and -i didn't seem to help. Updating the jest dependency seems to have worked.

[keatongreve]

+1 to @Enalmada's suggestion. i was on 20.0.x and since updating, my tests have no problems when running on Windows.

[mikechabot]

@cpojer Whether open-source or not, this lib sits under the header of a billion dollar corporation, and you want to outsource PRs? Cool story.