Jest: MacOS: Jest does not exit any more due to fsevents update

Created on 3 Nov 2020  路  15Comments  路  Source: facebook/jest

馃悰 Bug Report

Jest does not exit any longer after the tests are done on MacOS.

I tracked it down to the Update of [email protected]. Not sure if it might be better to open an issue there, or if you can fix it on your end. (Edit: I created https://github.com/fsevents/fsevents/issues/345)

As a workaround, I added the following to my package.json (through yarn):

"resolutions": {
  "**/jest-haste-map/fsevents": "2.1.3"
}

(Edit: Note that this workaround will fail installing on Windows and Linux. If you have a lock file (yarn.lock or package-lock.json), you should be able to set the version of fsevents to 2.1.3 there, see https://github.com/facebook/jest/issues/10777#issuecomment-722270678 below)

To Reproduce

Steps to reproduce the behavior:

Just run jest - I could reproduce it in a minimal repository with just Jest and a single test file.

package.json

{
  "name": "foo",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "test": "jest"
  },
  "dependencies": {
    "jest": "^26.6.2"
  }
}

foo.test.js

describe('test', () => {
  it('test', () => {
    expect(true).toBe(true)
  })
})

Expected behavior

Jest should exit after the tests are done.

envinfo

  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
  Binaries:
    Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm
  npmPackages:
    jest: ^26.6.2 => 26.6.2 

I also reproduced this on Node 14.1.0 and 15.0.1

Upstream Bug

Most helpful comment

Fixed upstream in 2.2.1 馃憤

All 15 comments

I believe I'm getting the same issue. I tried upgrading all kinds of dependencies/tools to see if any of that would fix it (along with trying other suggestions found around the net to fix hanging tests, such as uninstalling/reinstalling watchman on homebrew), but had no luck. I was wondering if it was some issue with a new version of jest, but the newest version I could find that doesn't hang out of the box was v24.9.0, which is pretty old at this point.

  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
  Binaries:
    Node: 14.15.0 - ~/.nvm/versions/node/v14.15.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v14.15.0/bin/npm
  npmPackages:
    jest: ^26.6.2 => 26.6.2

Thanks for the workaround @kryops 馃憤

Confirmed getting this on macOS, and @kryops temporary workaround solved this. Thanks!

I think this issue is ultimately related to another issue about --detectOpenHandles: https://github.com/facebook/jest/issues/9473

Same here. Broken on macOS

FWIW, if you can downgrade to node 10, that also seems to provide a temporary workaround.

Reporting to fsevents seems like a good idea. I haven't investigated on our side, but I don't _think_ we do anything weird.

EDIT: In case people miss the link below: fsevents/fsevents#345

After hitting these same issues all day... I upgraded jest to 26.6.3.

My tests are now exiting without the need for --forceExit, or any other workaround.

For those who use npm and cannot apply the resolutions workaround, you can directly modify your package-lock.json file to install the latest working fsevents version (2.1.3), though you'll have to be careful with the future updates.

After hitting these same issues all day... I upgraded jest to 26.6.3.

My tests are now exiting without the need for --forceExit, or any other workaround.

26.6.3 didn't fix the issue for me. But the Yarn resolutions fix resolved it.

yarn's resolutions is a foodgun for this, it will fail a install on other platforms because apparently yarn tries to explicitly install it and fails:

error [email protected]: The platform "linux" is incompatible with this module.

I think it's time to drop the fsevents dependency.

We won't be dropping fsevents (or rather, we'll be removing the direct dependency, but it will still be pulled in via chokidar in #10048).

If you have a lockfile (which you probably do if using yarn resolutions) you can ensure fsevents is on 2.1.3 in there and avoid the bug.

Here's a yarn.lock entry from my work project you can paste into your own lockfile. Ranges might vary, but as long as you also delete the entry for 2.2 yarn should make sure to keep using 2.1 after an install

fsevents@^2.1.2, fsevents@~2.1.2:
  version "2.1.3"
  resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.1.3.tgz#fb738703ae8d2f9fe900c33836ddebee8b97f23e"
  integrity sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==

For me, this worked on macOS and Linux both. putting fsevents in resolution would throw error in Linux and windows.

"resolutions": {
  "jest-haste-map": "^26.6.2"
}

Just for reference my yarn.lock have following versions after above change

[email protected]:
  version "2.1.2"
  ...
fsevents@^1.2.7:
  version "1.2.13"
  ...

fsevents@^2.1.2, fsevents@~2.1.2:
  version "2.1.3"
  ...

Fixed upstream in 2.2.1 馃憤

Is it normally fixed in latest Jest version? Because I'm running 26.6.3 and the bug is still happening for me. Or is the fixed version not released yet?

It is included. Check your package-lock.json and see in jest's dependencies if there is [email protected]. If it is, you need to clean install your modules. The fsevents version that solves the issue is v2.2.1

It fixed the problem for me, thanks! 馃槃 馃憤

Was this page helpful?
0 / 5 - 0 ratings