-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(jest-haste-map): handle injected scm clocks #10966
feat(jest-haste-map): handle injected scm clocks #10966
Conversation
CHANGELOG.md
Outdated
@@ -15,6 +15,7 @@ | |||
- `[jest-runner]` [**BREAKING**] Run transforms over `testRunnner` ([#8823](https://github.com/facebook/jest/pull/8823)) | |||
- `[jest-runtime, jest-transform]` share `cacheFS` between runtime and transformer ([#10901](https://github.com/facebook/jest/pull/10901)) | |||
- `[jest-transform]` Pass config options defined in Jest's config to transformer's `process` and `getCacheKey` functions ([#10926](https://github.com/facebook/jest/pull/10926)) | |||
- `[jest-haste-map]` Handle injected scm clocks ([#10966](https://github.com/facebook/jest/pull/10966)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you make it alphabetical? 😀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks clean to me, and stricter types is always good! I suppose we don't have a great place to document this?
@SimenB Yeah, I'm not sure about documentation. I'll go ahead and at least explain it further in code comments for anyone in the future that might be poking around for a similar use-case. |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
Jest's haste map supports incremental update. What this means is that when you first run Jest, a full rebuild of the map is done, but future invocations will only update changed files, which is pretty quick.
At Facebook, due to the size of our monorepo, we've taken this one step further. The first run of Jest downloads a version of the haste map that was created for a revision near yours. We then update it from there. This is done because doing a full rebuild takes several minutes.
To support this, we've been using a forked version of the Watchman crawler that supported doing an "SCM query". You can read about it here: https://facebook.github.io/watchman/docs/scm-query.html
The reason this is necessary is because Watchman clocks are not portable across systems; the haste map you create on your machine cannot by default be run on mine. The downloaded haste map contains a clock that references source control mergebases, which are portable.
This PR allows Jest, when it sees a specific type of clock that represents a source-control query, to handle it properly.
Rather than maintaining our own custom crawler, I'd like to upstream this. Upstreaming will make it simpler to distribute this to the variety of places that need it and may benefit others with a similar use-case; if any of them use hg and Watchman :)
Test plan
I added a unit test for this behavior. Specifically, the tricky part is that Watchman responds slightly differently to the query, with a divergence in
is_fresh_instance
andclock
fields. I also killed a variety ofany
types in this file for an extra layer of protection, since the crux of this diff involved changing response types.Additionally, I tested this end-to-end against FB infra to be sure it'll work properly in that context.