feat(metro-runtime): support using strings as module IDs #1132
+44
−91
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
facebook-github-bot
added
CLA Signed
EvanBacon
added a commit
to expo/expo
that referenced
this pull request
Jul 9, 2024
# Why - In React Server Components, we need deterministic module IDs since the bundles are not created together in development. - Metro's default require implementation only uses non-deterministic numeric IDs which is not just broken but it's also really hard to debug when a module is missing. - This PR brings over proposed changes from facebook/metro#1132 <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Fork the metro require implementation and hide it behind a flag `EXPO_USE_METRO_REQUIRE`. - Drop support for the require name hints since they assume that the module ID cannot be a string. - Create a custom build pipeline in CLI to support the special requirements of the metro runtime require module (cannot have module interop). # Test Plan - Forked the tests too so we can ensure parity with the standard system. - Added a new E2E web test to ensure the new bundles are runnable. --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
alanjhughes
pushed a commit
to expo/expo
that referenced
this pull request
Jul 17, 2024
# Why - In React Server Components, we need deterministic module IDs since the bundles are not created together in development. - Metro's default require implementation only uses non-deterministic numeric IDs which is not just broken but it's also really hard to debug when a module is missing. - This PR brings over proposed changes from facebook/metro#1132 <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Fork the metro require implementation and hide it behind a flag `EXPO_USE_METRO_REQUIRE`. - Drop support for the require name hints since they assume that the module ID cannot be a string. - Create a custom build pipeline in CLI to support the special requirements of the metro runtime require module (cannot have module interop). # Test Plan - Forked the tests too so we can ensure parity with the standard system. - Added a new E2E web test to ensure the new bundles are runnable. --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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
Using strings will make it easier to debug larger bundles by allowing users to optionally preserve module names with something like
serializer.createModuleIdFactory.Unclear how to support the
nativeRequirecode since it's unclear how it works, there's some sort of bit shift being performed on the numeric IDs.Probably also want to drop verbose module IDs since you can just use the string module IDs.
Test plan
TBD. Unclear if this fully works due to features that don't have comments or any usage in the repo.
I also can't get vs code to respect the flow types used in this file so I build it outside the repo and copy the changes in.