Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36625
## Context
Previously, jsRepresentation would only cache the **HostFunctions** returned from TurboModule::createHostFunction().
## Changes
This diff replaces TurboModule::createHostFunction() with TurboModule::create().
Now, jsRepresentation will cache **all** the **properties** returned from TurboModule::create().
## Motivation
For interop modules, constants will be exported as properties on the TurboModule HostObject. This diff allows those constants (which are non HostFunctions) to be cached.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44253229
fbshipit-source-id: d3dd042f4ccb6c076b83503f3712e4d1609388ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36626
In Bridgeless mode, With the TurboModule interop layer, the TurboModule system will need to customize the nativeModuleProxy global.
This customization would be much easier if the nativeModuleProxy global were installed by the TurboModule system (and not the Bridgeless core).
So, this diff moves nativeModuleProxy installation into the TurboModule system.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D43993197
fbshipit-source-id: 9361340c02e2d82c4e5f373f234f41dc9d72cbe4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36679
We expose a variant of `HermesExecutor.java` which allows you to set a custom max heap size. This variant also sets the `AllocInYoung/RevertToYGAtTTI`, which should never really be used without a matching call to `HermesInternal.ttiReached()`, which is not documented.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D44457318
fbshipit-source-id: e91b377cbc0ac596cfbe7d1178e2657b868c1067
Summary:
The `Renderer` directory is supposed to be only for files synced from the React repo. This moves the `public` directory that was added to it recently to the `ReactNative` directory.
Changelog: [internal]
bypass-github-export-checks
Reviewed By: sammy-SC
Differential Revision: D44421951
fbshipit-source-id: d098970b80cd467b5c772c3ae91ce716be373484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36659
## Changelog:
[Android][Fixed] - Fix dispatching into incorrect UIManager type when event's target is a root view
There is a function, called [ViewUtil.getUIManagerType](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/common/ViewUtil.java#L22), which infers whether we are using the new or old architecture, given a View tag ID, with the assumption being that all New Architecture tags are even (and therefore, we are in the New Architecture iff the view tag is even). See [here for more context](https://github.com/facebook/react/pull/12587/files).
This function was used to find out which type of event dispatcher to dispatch to, when going down the chain of event dispatching function calls on Android.
The problem is, that there may be cases, when this odd/even assumption breaks, in particular when the target view ID is equal to `1`, meaning that it's a root view ID and there is nothing else mounted there yet.
It's very rare that this happens in practice, but still is possible that user interacts with the screen before anything is mounted there (or if there is nothing mounted there by design).
Reviewed By: javache
Differential Revision: D44421739
fbshipit-source-id: fd5ba3c882f6c7d3c9543ebc2ec30ba000f7ca4f
Summary:
Currently we have a tool (rnx-kit/rn-changelog-generator) that extracts changelog messages from our commit history to generate the changelog for a React Native release.
In hopes of standardizing to one place where changelog validation occurs -- I've moved this logic to the package rnx-kit/rn-changelog-generator such that if the formatting ever changes, the changelog parsing is also updated.
Changelog: [Internal] - Updating danger to use logic in rnx-kit/rn-changelog-generator for changelog validation.
Pull Request resolved: https://github.com/facebook/react-native/pull/36507
Test Plan: Tried `require`-ing the package and on a changelog message. I'm not sure exactly how to test a dangerfile -- IIRC it has to run off `main`
Reviewed By: cortinico, cipolleschi
Differential Revision: D44183479
Pulled By: lunaleaps
fbshipit-source-id: f65440f7b66a048f961d4698d78210c74e276452
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36645
This broke while changing the AnimatedInterpolation back in D40571873 and D40632443, as I assumed the native side would be able to correctly handle values such as '1rad'. However these were being sent over as strings, and were thus using the string interpolation path, which does not work here.
Instead, handle both `deg` and `rad` explicitly when generating the config in JS.
Resolves issue https://github.com/facebook/react-native/issues/36608
Changelog: [General][Fixed] Resolves Animated.Value.interpolate results in NaN when output is in radians
Reviewed By: yungsters
Differential Revision: D44406034
fbshipit-source-id: fe0f3df16f2b8ec6c31f9359e4706cacc72b9951
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36662
For VR, JSPointerDispatcher skips calculating the delta of hit targets (which happens in onMove) on the frame in which the active controller is switched because the motion event is a DOWN event, not a MOVE event in that specific frame.
This diff fixes the issue by just calling onMove in addition to onDown for DOWN motion events. Unfortunately we do not have separate pointer IDs for each controller.
This won't change the behavior for non-hoverable pointers. For hoverable pointers, it will dispatch an extra pointer_enter if the hit path has changed between the last move event and the down event.
Changelog:
[Internal][Fixed] - Trigger pointer leave when active controller switched
Reviewed By: lunaleaps, javache
Differential Revision: D44377324
fbshipit-source-id: 9f668e64f486b9a12ab36563ec2b7cf93f208a54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36648
Changelog: [Internal]
Blocker for https://github.com/facebook/react-native/pull/36623. The `test-ios` job in CI was misconfigured following the monorepo migration — and this becomes load-bearing with the incoming version of React Native CLI.
- Update `objc-test.sh` to run in `packages/rn-tester`, and exclude tests under `/IntegrationTests` which are outside of a Metro project directory.
- **This is temporary** — a task has been created to move/split up/otherwise restore tests in `IntegrationTests`, which cipolleschi is following up (thanks!).
- Also fix `yarn start` script in `packages/rn-tester`.
Reviewed By: cipolleschi
Differential Revision: D44416533
fbshipit-source-id: 59c5b743d9d8fda206a12e37d94324ed9bfd703e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36568
Changelog: [Internal]
Okay, so before the monorepo migration we had to use two scripts separately:
1. Bumping every package with `npm run bump-all-updated-packages`
2. Aligning other packages versions with `npm run align-package-versions`
The reason for it is that *before the monorepo* in a release branch cutoff process we had a step, which was removing `workspaces` keyword from `react-native` package. Without this keyword all new versions of packages will be resolved from npm (where they will be not available yet, because we have to publish them prior to it)
This is not the case for our current setup, and we can actually bump packages versions and they will be resolved as a workspaces successfully
Reviewed By: cortinico, cipolleschi
Differential Revision: D44261057
fbshipit-source-id: 31c2157be2d3b33bc073651d6045efcef2e8f5c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36575
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all.
We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding.
Changelog:
[Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()`
Reviewed By: javache
Differential Revision: D44298159
fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36634
X-link: https://github.com/facebook/metro/pull/957
The existential type `*` has been deprecated and just an alias for `any` since version 0.163. Codemod usage of it to `any`.
This helps with diff D44276187, which makes it always an error to use `*`.
Changelog: [internal]
Reviewed By: pieterv, SamChou19815
Differential Revision: D44358809
fbshipit-source-id: c6bb55430edd086958e16989c60bc2a0a131a3fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36577
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change allows us to strip CustomStyleSpan. We already set all but `fontVariant` on the underlying EditText, so we just need to route that through as well.
Note that because this span is non-parcelable, it is seemingly not subject to the buggy behavior on Samsung devices of infinitely cloning the spans, but non-parcelable spans have different issues on the devices (they disappear), so moving `fontVariant` to the top-level makes sense here.
Changelog:
[Android][Fixed] - Minimize EditText Spans 8/N: CustomStyleSpan
Reviewed By: javache
Differential Revision: D44297384
fbshipit-source-id: ed4c000e961dd456a2a8f4397e27c23a87defb6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36576
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change addresses some minor CR feedback and removes the temporary list of spans in favor of applying them directly.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D44295190
fbshipit-source-id: bd784e2c514301d45d0bacd8ee6de5c512fc565c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36548
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change lets us set `letterSpacing` on the EditText instead of using our custom span.
Changelog:
[Android][Fixed] - Minimize EditText Spans 6/N: letterSpacing
Reviewed By: rshest
Differential Revision: D44240777
fbshipit-source-id: 9bd10c3261257037d8cacf37971011aaa94d1a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36544
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change makes us apply strikethrough and underline as paint flags to the underlying EditText, instead of just the spans. We then opt ReactUnderlineSpan and ReactStrikethroughSpan into being strippable.
This does actually create visual behavior changes, where child text will inherit any underline or strikethrough of the root EditText (including if the child specifies `textDecorationLine: "none"`. The new behavior is consistent with both iOS and web though, so it seems like more of a bugfix than a regression.
Changelog:
[Android][Fixed] - Minimize Spans 5/N: Strikethrough and Underline
Reviewed By: rshest
Differential Revision: D44240778
fbshipit-source-id: d564dfc0121057a5e3b09bb71b8f5662e28be17e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36545
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds ReactForegroundColorSpan to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 4/N: ReactForegroundColorSpan
Reviewed By: javache
Differential Revision: D44240780
fbshipit-source-id: d86939cc2d7ed9116a4167026c7d48928fc51757
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36547
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds `ReactBackgroundColorSpan` to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 3/N: ReactBackgroundColorSpan
Reviewed By: javache
Differential Revision: D44240782
fbshipit-source-id: 2ded1a1687a41cf6d5f83e89ffadd2d932089969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36546
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change generalizes `stripAttributeEquivalentSpans()` to allow plugging in different spans.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D44240781
fbshipit-source-id: 89005266020f216368e9ad9ce382699bd8db85a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36543
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
We cache the backing EditText span on text change to later measure. To measure outside of a TextInput we need to restore any spans we removed. Spans may overlap, so base attributes should be behind everything else.
The logic here for dealing with precedence is incorrect, and we should instead accomplish this by twiddling with the `SPAN_PRIORITY` bits.
Changelog:
[Android][Fixed] - Minimize Spans 1/N: Fix precedence
Reviewed By: javache
Differential Revision: D44240779
fbshipit-source-id: f731b353587888faad946b8cf1e868095cdeced3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36621
After D44302691 enabled textShadow, there was a subtle 1px shadow on any new text which I did't spot, but screenshot tests did (after commit which is non-ideal, but there is more work to make these land blocking).
This is because unlike `ReactBaseTextShadowNode` in paper which defaults to a radius of zero (no shadow), `TextAttributes` in Fabric defaults to a radius of 1px. Just previously never displayed.
Without shadow:
https://pxl.cl/2z2wX
With shadow:
https://pxl.cl/2z2x0
This changes the default to zero, which will cause us to skip adding the span, and matches previous behavior in Paper.
I double-checked the other props are defaulted the same way between `BaseTextShadowNode` (Paper) and `TextAttributes` (Fabric).
Changelog:
[Android][Fixed] - Fix default shadow radius in TextAttributeProps
Reviewed By: javache
Differential Revision: D44364446
fbshipit-source-id: d207367608291048001403d292f881c0842113f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36541
We only know where the last focused cell lives after it is rendered. Apart from dead refs handled in D43835135, this means items added or removed before the focused cell will lead to a stale last index for the next state update.
We don't have a good way to correlate cells after data change. This effects the implementation for [`maintainVisibleContentPosition`](https://github.com/facebook/react-native/pull/35993) as well, but needs some thought on the right way to handle it. For now, we bail when we don't know where the last focused cell lives.
Changelog:
[General][Fixed] - Bail on realizing region around last focused cell if we don't know where it is
Reviewed By: yungsters
Differential Revision: D44221162
fbshipit-source-id: 8fc7e726fe13c62b98870600563857bb89290280
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36585
1. We don't add `ShadowStyleSpan` unless an offset is set. This is incorrect, and less permissive than `BaseTextShadowNode` in Paper.
2. We don't serialize textShadowOffset to MapBuffer
Changelog:
[Android][Fixed] - Fix textShadow on Android Fabric
Reviewed By: javache
Differential Revision: D44302691
fbshipit-source-id: 2cfd3bff3d0e4f329c98d1ed2defff94ad3b7dc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36582
This change should fix the path to run packager.sh directly from Xcode, this was broken after the Monorepo work.
## Changelog:
[internal] - update path to run packager.sh
Reviewed By: huntie, hoxyq
Differential Revision: D44292167
fbshipit-source-id: 90e0291aa7a15189c72cae99c5d38c84c7243a80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36609
Some random cleanup as I prepare to make these classes a better injection point for future experiments.
* Forward-declare classes where possible to reduce header import
* Return references to shared_ptr instead of copies when there are no lifetime concerns
* Use a shared JClass instance in JFabricUIManager
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D44221018
fbshipit-source-id: 1660cac964abd10ce798473e26841503430efdfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36591
If any of the properties used in event-emitter codegen conflict with `event` or `payload`, the generated code will fail to build, even if this generated code isn't used. Since these are quite common keys, prefix them with `$` (still valid C++) to avoid conflicts.
Changelog: [General][Fixed] Resolved property name conflicts in event-emitter codegen
Reviewed By: cipolleschi
Differential Revision: D44274619
fbshipit-source-id: 45e67850c49e082d8f9b1f85bb632d45a9fd4f1d
Summary:
X-link: https://github.com/facebook/metro/pull/955
Pull Request resolved: https://github.com/facebook/react-native/pull/36584
Changelog:
[General][Changed] - Default condition set for experimental Package Exports is now `['require', 'react-native']`
The [Exports RFC](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0534-metro-package-exports-support.md) had assumed that supporting the `"import"` condition was a syntax-only difference, given we are not in a Node.js environment — and so was worthwhile to support for maximal ecosystem compatibility.
{F915841105}
This assumption is similar to [`--moduleResolution bundler` in TypeScript 5.0](https://github.com/microsoft/TypeScript/pull/51669):
> bundlers and runtimes that include a range of Node-like resolution features and ESM syntax, but do not enforce the strict resolution rules that accompany ES modules in Node or in the browser
> -- https://github.com/microsoft/TypeScript/pull/51669#issue-1467004047
However, robhogan has rightly pointed out that **we should not do this!**
- ESM (once transpiled) is **not** simply a stricter subset of in-scope features supported by CJS. For example, it supports top-level async, which would be breaking at runtime.
- We recently made the same change for our Jest environment:
- https://github.com/facebook/react-native/commit/681d7f8113d2b5e9d6966255ee6c72b50a7d488a
As such, we are erring on the side of correctness and supporting only `['require', 'react-native']` in our defaults. At runtime, all code run by React Native is anticipated to be CommonJS. `"exports"` will instead allow React Native to correctly select the CommonJS versions of modules from all npm packages.
Metro changelog: [Experimental] Package Exports `unstable_conditionNames` now defaults to `['require']`
Reviewed By: robhogan
Differential Revision: D44303559
fbshipit-source-id: 0077e547e7775e53d1e4e9c3a9d01347f4fb7d4a
Summary:
We used to have to install python 3 on windows. Starting from yesterday (22/03/2023) the `build_hermesc_window` job started failing because Python3 is already installed on the default machine.
## Changelog:
[INTERNAL] [FIXED] - Skip installing python 3 on Windows as it's already there.
Pull Request resolved: https://github.com/facebook/react-native/pull/36596
Test Plan: CircleCI must be green
Reviewed By: hoxyq
Differential Revision: D44330936
Pulled By: cipolleschi
fbshipit-source-id: b58190f707be309d919aceb80af717046c9476b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36581
Found that the current codegen did not properly handle a return type of `?bool` because the branch of `constexpr (is_optional_v<T>)` assumed that T was always a JSI value that needed conversion, and `supportsToJs<bool, bool>` is false.
Changelog: [General][Fixed] Issue with TurboModule C++ codegen with optional return types
Reviewed By: christophpurrer
Differential Revision: D44302352
fbshipit-source-id: 0863de06da4e5e3c18f8a1ced7179d76d8e87b99
Summary:
Task from https://github.com/facebook/react-native/issues/34872
> [Codegen 80] Convert the emitCommonTypes implementation from a switch based implementation to a dictionary based one
## Changelog:
[Internal] [Changed] - Convert the emitCommonTypes implementation from a switch based implementation to a dictionary based one
Pull Request resolved: https://github.com/facebook/react-native/pull/36549
Test Plan: `yarn test react-native-codegen`
Reviewed By: NickGerleman
Differential Revision: D44244901
Pulled By: rshest
fbshipit-source-id: 50712724c72aad3bd1dae3e7c381242c4913a236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36571
Changelog: [Internal]
The problem is related to the way we use `js_srcs_dir` & `output_dir` options, one requires just relative path from current ruby script, other requires relative path from iOS root project (where the Podfile located)
output_dir was introduced in D43304641
resulted into the issue, described in https://discord.com/channels/514829729862516747/1087736932953509958
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D44294112
fbshipit-source-id: 47fcf510e203d0880e1f92ab6ead09f4b79cb4dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36570
I'm doing some preparations to implement this proposal to bring some DOM APIs to React Native refs: https://github.com/react-native-community/discussions-and-proposals/pull/607
To make it easier to iterate on the proposal, and to improve the separation of concerns between React and React Native, I'm moving the definition of `ReactFabricHostComponent` (the public instance provided by React when using refs on host conmponents) to the `react-native` package.
I already did some steps in the React repository to simplify this:
* Removing unused imperative events that caused increased coupling: https://github.com/facebook/react/pull/26282
* Extracting the definition of the public instance to a separate module: https://github.com/facebook/react/pull/26291
In this case, in order to be able to move the definition from React to React Native, we need to:
1. Create the definition in React Native and export it through `ReactNativePrivateInterface`.
2. Update React to use that definition instead of the one in its own module.
This diff implements the first step.
`ReactNativeAttributePayload` is required by this definition and by the one for Paper that still exists in React. I moved it here so we only define it where we use it when we remove Paper. Paper will access it through `ReactNativePrivateInterface` as well. That will also allow us to remove a few other fields in that interface.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: yungsters
Differential Revision: D43772356
fbshipit-source-id: 78dac152f415f19316ec90887127bf9861fe3110
Summary:
A quick fix for the local e2e script, a path needed to be updated.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - fix e2e local script post monorepo refactoring
Pull Request resolved: https://github.com/facebook/react-native/pull/36558
Test Plan: Run it locally.
Reviewed By: cortinico, cipolleschi
Differential Revision: D44257019
Pulled By: hoxyq
fbshipit-source-id: 29c4d4d103b5a041ef241cd371f31a1fc41d0396
Summary:
## Changelog:
[Internal] -
Update the pods, which appear to be out of date, due to the corresponding OSS jobs being broken,
allow-large-files
Reviewed By: christophpurrer
Differential Revision: D44282378
fbshipit-source-id: 1d182361f26e692ba83ac6ec3d557e01e7281a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36513
We don't use JS test coverage badge on GitHub. Collecting this information is performed by `coveralls` package that is unmaintained for at least 2 years. Also it depends on `request` package that has security vulnerabilities, and became deprecated in 2020.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D44168060
fbshipit-source-id: f76ae28f42b65e320a71dc227b2d07274a96f24e
Summary:
Changelog: [General][Removed] Remove experimental support for loading bytecode from Metro
Removes the experimental bundling strategy that offloads Hermes bytecode compilation to the packager server. The React Native parts of this experiment were never part of the public API, and the Metro parts never fully shipped in open source.
Followup from D43597007.
Reviewed By: robhogan
Differential Revision: D43604705
fbshipit-source-id: db3be553750ccbf286d876f75858299c5b750f19
Ramanpreet Nara
Pieter De Baets
Rubén Norte
Ruslan Shestopalyuk
David Richey
Luna Wei
Genki Kondo
Alex Hunt
Ruslan Lesiutin
MaeIg
Nick Gerleman
Marshall Roch
George Zahariev
Genki Kondo
Soumyajit Behera
Riccardo Cipolleschi
Lulu Wu
Kyaw Thura
Pieter De Baets
Lorenzo Sciandra
Dmitry Rykun
Moti Zilberman
