Skip to content
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

Merged
merged 4 commits into from Dec 22, 2020

Conversation

scotthovestadt
Copy link
Contributor

@scotthovestadt scotthovestadt commented Dec 22, 2020

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 and clock fields. I also killed a variety of any 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.

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))
Copy link
Member

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? 😀

Copy link
Member

@SimenB SimenB left a 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?

@scotthovestadt
Copy link
Contributor Author

@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.

@SimenB SimenB merged commit b51564b into jestjs:master Dec 22, 2020
@scotthovestadt scotthovestadt deleted the watchman-crawler-scm-clock branch December 22, 2020 20:02
@github-actions
Copy link

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants