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

Open source our jest-haste-map fork as metro-file-map #812

Closed
wants to merge 1 commit into from

Conversation

robhogan
Copy link
Contributor

Summary:

Motivation

Internally at Meta we need to make various modifications to jest-haste-map for use by Metro (eg instrumentation, internal cache support), which up to now we've achieved using a fork, a subclass, the hasteMapModulePath option and some monkey-patching.

This isn't an ideal situation, and we're also coming up against the limits of what we can do whilst remaining faithful to the jest-haste-map API. We don't want to bloat an open source Jest subpackage (which rightly serves Jest first) with Metro-specific accommodations, and we want to be able to make changes, including breaking changes, at Metro's release cadence.

Approach

Therefore, we're publishing our lightly-modified fork of jest-haste-map@27.3.1 as metro-file-map and making it a first-class Metro citizen, with the intention to decouple from Jest and make updates and modifications with fewer constraints.

jest-haste-map is still heavily in use at Meta by Jest itself, so we'll still look to share/upstream as much as makes sense, and we'll be open to re-partitioning (for direct code sharing) or even re-converging down the line.

Possibilities

Additionally, I'm optimistic that reducing the friction around Metro-oriented file crawling/watching might enable/encourage tackling some longstanding issues, such as symlink support and lazy loading.

Reviewed By: motiz88

Differential Revision: D35744151

Summary:
## Motivation
Internally at Meta we need to make various modifications to `jest-haste-map` for use by Metro (eg instrumentation, internal cache support), which up to now we've achieved using a fork, a subclass, the `hasteMapModulePath` option and some monkey-patching.

This isn't an ideal situation, and we're also coming up against the limits of what we can do whilst remaining faithful to the `jest-haste-map` API. We don't want to bloat an open source Jest subpackage (which rightly serves Jest first) with Metro-specific accommodations, and we want to be able to make changes, including breaking changes, at Metro's release cadence.

## Approach
Therefore, we're publishing our lightly-modified fork of `jest-haste-map@27.3.1` as `metro-file-map` and making it a first-class Metro citizen, with the intention to decouple from Jest and make updates and modifications with fewer constraints.

`jest-haste-map` is still heavily in use at Meta by Jest itself, so we'll still look to share/upstream as much as makes sense, and we'll be open to re-partitioning (for direct code sharing) or even re-converging down the line.

## Possibilities
Additionally, I'm optimistic that reducing the friction around Metro-oriented file crawling/watching might enable/encourage tackling some longstanding issues, such as [symlink support](facebook#1) and [lazy loading](jestjs/jest#12231).

Reviewed By: motiz88

Differential Revision: D35744151

fbshipit-source-id: 0e2b621dccec464b377b0ae0d91436149890b1d7
@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported labels Apr 27, 2022
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D35744151

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants