Jest crawls FS with --runTestsByPath passed

[segrey]

🐛 Bug Report

Jest crawls the file system even an exact test file path is specified. Thus, the test run is slower than it could be.

To Reproduce

Open https://github.com/facebook/jest/tree/master/examples/jquery and install dependencies.
Run only needed exact test file path to speed up the test run:

jest --runTestsByPath __tests__/fetch_current_user.test.js

Function nodeCrawl (https://github.com/facebook/jest/blob/v23.6.0/packages/jest-haste-map/src/crawlers/node.js#L130) is called (options.roots contains the project root).

Expected behavior

The file system is not crawled => faster test run.

Run npx envinfo --preset jest

Paste the results here:

  System:
    OS: Windows 10
    CPU: x64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
  Binaries:
    Yarn: 1.7.0 - C:\Users\Sergey.Simonchik\AppData\Roaming\npm\yarn.CMD
    npm: 6.1.0 - C:\Program Files\nodejs\npm.CMD

[SimenB]

The way we do it now is that we always first crawl the fs (unless it's available in the cache), then apply filters. It makes for a pretty straight forward data flow no matter what filters you apply, and makes the logic easier to reason about.

Not sure if it's worth it to change. Do you think (or even better measured) it has much impact?

[segrey]

@SimenB Thanks for the replay. Originally, the issue came from https://youtrack.jetbrains.com/issue/WEB-34429. Personally, I haven't reproduced any significant slow down on jest project: crawling the fs took ~50 ms on mine SSD. I guess, it will take more on HDD.

[SimenB]

If we could prove that it significantly speeds up execution I think it makes sense to look into. But right now I'm a bit afraid that it'll increase the complexity for no real gain. An alternative is to use watchman, which makes the crawl much faster (and "free" on subsequent calls because it's cached)

---

Off topic, but it would be interesting if we could turn jest into a server of sorts, which you could send commands to to trigger test runs. This would make the crawl a one-time cost cached or not. Useful for all IDE integrations

[segrey]

@SimenB You're probably right that it won't provide any significant execution speed up, at least in my experience. Feel free to close until more measurements confirming the real benefits of no crawling are provided.
Regarding turning jest into a server, IIUC, that's how Karma works now, right? Indeed, one-time crawling would be needed only. Though, it would make IDE integrations a bit trickier.

[SimenB]

Issue for daemon: #5950.

Closing, but happy to reopen if we're able to prove that there is a lot of gain to be had by short-circuiting the initial crawl

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.