Open source our jest-haste-map fork as metro-file-map
#812
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D35744151 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Motivation
Internally at Meta we need to make various modifications to
jest-haste-mapfor use by Metro (eg instrumentation, internal cache support), which up to now we've achieved using a fork, a subclass, thehasteMapModulePathoption 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-mapAPI. 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.1asmetro-file-mapand making it a first-class Metro citizen, with the intention to decouple from Jest and make updates and modifications with fewer constraints.jest-haste-mapis 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