Jest: --watch Now Throws an Error

[arb]

🐛 Bug Report

I recently updated jest to 24.3.1 and now running with --watch throws an error and does not start. The error is:

2019-03-08 09:51 node[1373] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
Error: Error watching file for changes: EMFILE
    at _errnoException (util.js:1022:11)
    at FSEvent.FSWatcher._handle.onchange (fs.js:1359:9)

I do _not_ have watchman installed globally and again, this was working yesterday and now it's not. I feel like it's an issue with the macOS update but I can't confirm. I know installing watchman via brew is a suggested solution but I've never had to do that before and that seems kind of like it's masking a possible issue with jest.

To Reproduce

npx jest --watch

Expected behavior

I expected jest to continue to work correctly as it has before I updated.

Link to repl or repo (highly encouraged)

https://github.com/arb/celebrate/tree/feature-ref this is the branch I'm working with and currently exhibiting the above behavior.

Run npx envinfo --preset jest

Paste the results here:

npx: installed 1 in 1.538s

  System:
    OS: macOS 10.14.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Binaries:
    Node: 8.11.1 - ~/.nvm/versions/node/v8.11.1/bin/node
    Yarn: 1.9.4 - ~/.nvm/versions/node/v8.11.1/bin/yarn
    npm: 5.6.0 - ~/.nvm/versions/node/v8.11.1/bin/npm
  npmPackages:
    jest: ^24.3.1 => 24.3.1 

[SimenB]

You can probably install watchman to get around this - brew install watchman.

This is probably because we removed the fsevents crawler (#8048). Not sure why the node crawler explodes, tho.

[arb]

@SimenB I'd rather not do that. Like I said in the initial issue, that seems to be masking an actual issue with jest. If I install watchman, reproducing the problem becomes harder.

[SimenB]

Sure, I was just trying to unblock you

[thymikee]

I tried to run it with yarn (so fresh install) and don't see the error – it's probably related to deps update, so please clean it up. However I can see the same message as here: https://github.com/facebook/jest/issues/8084.

[thymikee]

Closing as duplicate of #8084

[arb]

@thymikee how is this a duplicate of #8084? The error message is completely different and I'm not using the --changedSince flag either.

[thymikee]

This is the error I get when running --watch on your repro, feature-ref branch:

 FAIL   test  test/celebrate.test.js
  ● Test suite failed to run

    TypeError: options.changedFiles.has is not a function

FYI --watch and --changedSince share a lot of logic.

[arb]

I see. Thank you for the clarification! I didn't get that MUCH more specific error when I'm running locally, but I agree, the root cause seems to be the same as #8084.

[SimenB]

Seems this is still an issue for folks

[yoshicarroll]

It is, yes. Jest 23 worked fine. As soon as I updated to Jest 24 24.4.0 it started breaking.

[arb]

@yoshicarroll what version of macOS are you running? I'm starting to think that is the common thread.

[yoshicarroll]

@arb High Sierra 10.13.6

[arb]

Interesting, well it's not that then; I'm on 10.14.3.

[yoshicarroll]

I don't know anything about Jest internals, but if someone can point me to where to set a breakpoint and collect some info, I have some time to help out.

[elkwood]

I was able to alleviate the issue in my project that is experiencing this by configuring the watchPathIgnorePatterns to ["node_modules"]. As expected, this lowered the number of files being watched to something below my system's limit.

https://jestjs.io/docs/en/configuration.html#watchpathignorepatterns-array-string

[arb]

Can confirm this workaround gets around the problem. Make sure you specify the value on the project config if you're using multiple projects. I still believe there needs to be a code fix for this as it was working in version 23, but this is a good workaround for the current problem! 👍

[yoshicarroll]

This workaround resolves the errors for me as well, thanks @elkwood.
And, like @arb I too believe a code fix should fix the underlying issue.

[SimenB]

My guess is that this is caused by #8048. Maybe we can get sane to re-add fsevents seeing as it'll be easier to install in tue future?

[brneto]

I had issue I see here using jest and the only way I could fix that was installing watchman.
Here my environment:

System:
    OS: macOS 10.14.3
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
  Binaries:
    Node: 11.12.0 - /usr/local/bin/node
    Yarn: 1.15.2 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.5.0 => 24.5.0 

If now is necessary we install watchman to run jest, why that information isn't in Jest website (or documentation)? I needed to do a long research till I get here. Including that information into Jest page installation instruction would make jest user's life a lot easier.

Why not just include this information somewhere in Jest website?

[BoraALAP]

I'm learning react and I was testing redux actions, I installed es-lint to project (for no reason) and start getting the same error. Deleted node-modules and removed es-lint from the project. Everything went back to normal. I don't think this information helps you at all :), but just wanted to let you know es-lint might be part of the issue as well for you guys too.

[gaearon]

This issue is a blocker for next Create React App release, which by itself blocks several important updates (including React Hooks lint rules).

If we can't resolve it on the sane level, can we bring fsevents back into Jest directly?

I'm worried about the path forward here.

[SimenB]

I wonder if we can solve this in sane with the next release of fsevents, which won't require building native dependencies (it'll use n-api).

EDIT: We can probably just vendor it for now, we already vendor their watchman implementation (https://github.com/facebook/jest/blob/2bc62803ba457a3139c9533835a6888a824ddf4f/packages/jest-haste-map/src/lib/WatchmanWatcher.js)

EDIT2: pasted wrong link above originally, now fixed

[scotthovestadt]

@SimenB why are we watching node_modules by default? I understand doing it when Watchman makes it “free”, but otherwise...? Is there historical context I’m missing?

[thymikee]

@scotthovestadt you may ask @cpojer about that, but if we could only watch node_modules by default when watchman is enabled, that would be nice.

[scotthovestadt]

Or just a shallow watch of the folder, which would be nice because it would catch new modules. I’ll take a look today.

[SimenB]

No idea, maybe @cpojer can chime in. But I guess the point is, since watchman makes it free, they should behave as close as possible? If it's blocking CRA though, they can probably configure Jest to not watch node_modules?

[cpojer]

People get upset when we aren't watching node_modules because people tend to change them manually.

[elkwood]

I'm not sure that ignoring node_modules will fix the issue for everyone who uses Jest. I can imagine large applications where you still reach the file system's watch limit even if you do ignore node_modules. Probably not the repo I'd want to maintain, but I'm sure they exist.

[scotthovestadt]

@elkwood Yeah, going with an alternate solution (see https://github.com/facebook/jest/pull/8258), may revisit defaults on watching node_modules in the future if have more issues in this area.

[SimenB]

Fix out in 24.7.0

[baixiaoji]

having same error [email protected], but using 24.7.1 is ok

[SimenB]

That's a different error then, please open up a new issue

[baixiaoji]

That's a different error then, please open up a new issue

so you already known the error? but I reinstall [email protected], the error has gone

[SimenB]

No, but the error talked about in this issue has been fixed.

[normancarcamo]

I confirm that ignoring the node_modules worked again:

{
  "watchPathIgnorePatterns": ["node_modules"]
}

[email protected] doesn't solve the issue for me :/

[jeffbski-rga]

Problem still exists in [email protected] but configuring watchPathIgnorePatterns to ignore node_modules does fix.