Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49922
Spamming the DB with "heartbeat" events with close to 0 ping didn't give us any useful information. Instead, report high ping situations.
Changelog:
[General][Internal] Remove reporting all device and debugger heartbeat events, only report heartbeats with high round trip latency
Reviewed By: GijsWeterings
Differential Revision: D70707457
fbshipit-source-id: 6bc8a55fd32dfa60fb4f7764ac00a6218417dcb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49816
Previously, we had different versions of "debug" installed in different packages, mostly because of messed up `yarn.lock` entries.
Also, updated the package, receiving some performance improvements (no relevant breaking changes).
Changelog:
[General][Internal] update and dedupe the npm package "debug"
Reviewed By: huntie
Differential Revision: D70402368
fbshipit-source-id: 5e21bc6d92e0cb45ac1d862f100ef6dc0f21dbc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49726
The `InspectorProxy` debug logging became incredibly spammy making it almost unuseful unless the output is manipulated so this commit batches all these cdp messages and only desplays how many were received in the span of 5s. If no messages are received, the throttle is not triggered.
To get the actual CDP messages logged, we still log these to `Metro:InspectorProxyCDPMessages`.
Changelog:
[General][Internal] batch debug logging for cdp messages
Reviewed By: robhogan
Differential Revision: D70324724
fbshipit-source-id: a269302f52e18af6c4be651758c042596abdbad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49741
While the test delay `PAGES_POLLING_DELAY` is usually enough to be equal to `PAGES_POLLING_INTERVAL`, in some cases we need extra time to sync that with the polling in `Devices.js`.
Changelog:
[General][Internal] - fix test
Reviewed By: huntie
Differential Revision: D70384823
fbshipit-source-id: ccb18884d32dc27636dbbb3a9786412056f90830
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49714
Changelog: [internal]
This package was only needed for testing but it's actually not used.
Reviewed By: hoxyq
Differential Revision: D70318040
fbshipit-source-id: b57ec74932029368117520646972bfee83706017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49635
Changelog:
[General][Internal] - report proxy idle state in heartbeat events
The proxy is considered Idle if it didn't receive any messages for 10 seconds.
Reviewed By: robhogan
Differential Revision: D70078637
fbshipit-source-id: 5b8d9a3a6e3e2568e40b3ada0a41e76b277fe66d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49618
Changelog:
[General][Internal] - create a heartbeat for device, and not only for debugger.
Introducing a heartbeat for the connection between the proxy and the device similarly to the one between the proxy and the debugger. This will allow us to:
* Most importantly I'd like to track the ping-pong roundtrip to the device as well, to see if we have any anomalies there
* Terminate the connection if it is abandoned for 60seconds- this might have a real effect in some case where the device runs remotely
* Also keep that connection alive if the other side disconnects after a period of inactivity. While a no-op in our case, this is an implementation detail. It is a no-op because the WebSocket on the Device is implemented by us and is not supposed to drop connections like the browser does.
Reviewed By: robhogan
Differential Revision: D69990715
fbshipit-source-id: 6bb3a2ed3eaffff9535aa2d0fc8cff0262af022f
Summary:
This package does not seem to be referenced by anything but the tests in `packages/dev-middleware`, so seems like a pretty straightforward change to drop it from `dependencies`.
It only seems to be referenced in `packages/dev-middleware/src/__tests__/ServerUtils.js`
## Changelog:
[INTERNAL] [CHANGED] - Remove selfsigned from dev-middleware dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/49556
Test Plan: - n/a
Reviewed By: cipolleschi
Differential Revision: D69925928
Pulled By: huntie
fbshipit-source-id: bba41f81dba054505ebf196ad37c7a718a6b16da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49552
Changelog:
[General][Internal] - expand debugger events to have DebuggerSessionIDs
Also moved the handling of these to a shared function
Reviewed By: huntie
Differential Revision: D69917817
fbshipit-source-id: 2374ac5b5dc0040b0e15028ab89fbe78026bc296
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49499
Changelog:
[General][Internal] - warn when user tries to open DevTools, when not in debug mode
Reviewed By: huntie
Differential Revision: D69784836
fbshipit-source-id: aa60762f08f5dea1f91f4fd1ffc86eeb7f94e2fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49461
Flow now supports Package Exports 🎉. This means we can delete the compatiblity pattern in each of our build-enabled Node.js packages.
This simplifies the internal package structure needed to support Flow while developing from source in the monorepo — no prod impact.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D69741143
fbshipit-source-id: 070715cb6beb00eb393186dbf95856ceb87fabef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49441
Changelog:
[General][Internal] - keep heartbeat between inspector proxy and debugger going even if not idle
When heartbeat was only used to keep the connection alive and to detect debugger timeouts, it was enough to send a ping every time the connection was idle for 10 seconds.
Now, when we use the heartbeat as a way to track how good is the round trip time between the inspector proxy and the debugger, we would like to make this tracking more reliable by sending a ping 10 seconds after each pong, even if the connection is not idle.
It also simplifies the code and makes it more clear by removing the confusing `shouldSetTerminateTimeout` variable.
Reviewed By: hoxyq
Differential Revision: D69665738
fbshipit-source-id: c8175b54d2b3df32ee60b316ec7bcf7bc0f0a1ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49358
When the network is under strain, the code responsible for detecting if the inspector proxy's connection to the client has been lost may incorrectly assume the connection is dead. This false positive occurs because the system assumes that if a pong is not received within 5 seconds of a ping, the other side has disconnected. However, I was able to consistently reproduce scenarios where a delay of more than 5 seconds (even more than 20 seconds) was followed by a return to normal ping-pong communication without any issues.
Since I can't think of any issues with increasing this number, I'm increasing it to 60s.
Changelog:
[General][Fixed] - Disconnections of DevTools when the network is under significant strain.
Reviewed By: robhogan, huntie
Differential Revision: D69523906
fbshipit-source-id: 50db1e7bbe690b42421bc226aa30fd6571ba2257
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49353
This change adds an opt-in to restore JavaScript log streaming via the Metro dev server, [removed from React Native core in 0.77](https://reactnative.dev/blog/2025/01/21/version-0.77#removal-of-consolelog-streaming-in-metro).
Users can opt into this legacy behaviour by adding the `--client-logs` flag to `npx react-native-community/cli start`.
- The default experience remains without streamed JS logs.
- The existing "JavaScript logs have moved! ..." notice is printed in all cases, and we do not advertise the new flag for new users.
- Under non-Community CLI dev servers (i.e. Expo), log streaming is restored implicitly.
We will clean up this functionality again when we eventually remove JS log streaming over `HMRClient`, tasked in T214991636.
**Implementation notes**
- Logs are always sent over `HMRClient` (previous status quo), even with log streaming off in the dev server. This is a necessary evil to be able to flag this functionality in a user-accessible place, and to move fast for 0.78.
- Necessarily, emitting `fusebox_console_notice` moves to the dev server itself, on first device (Fusebox) connection.
Changelog:
[General][Added] - Add opt in for legacy Metro log streaming via `--client-logs` flag
Reviewed By: robhogan
Differential Revision: D69469039
fbshipit-source-id: be99d02a3b1c977a59bf7d2726f0e6cf2e60b28a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49102
Moves this script one level up. In the next diff, will be used to support execution of scripts themselves, as well as `packages/`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D68960279
fbshipit-source-id: 7b62420c269dc1c1366ac9a827db078d34cb86c5
Summary:
`dev-middleware` uses `invariant` but does not declare it as a dependency. Under certain hoisting scenarios, or when using pnpm, this will cause `dev-middleware` to fail while being loaded.
## Changelog:
[GENERAL] [FIXED] - add missing `invariant` dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/49047
Test Plan: n/a
Reviewed By: cortinico
Differential Revision: D68835789
Pulled By: huntie
fbshipit-source-id: 13718f4970ed55e6e062b7c2bd719be977abdd0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49001
In {D42973408}, `Debugger.scriptParsed` was tweaked to be intercepted in `inspector-proxy`, which:
1. Rewrote the `sourceMapURL` to be relative to debugger.
2. Attempted to fetch the contents of the source map from `sourceMapURL` after re-writing again to a server-relative URL, and if successful replaced `sourceMapURL` with a base64 data URL.
1 is still needed until we have `Network.loadNetworkResource`, but 2 was only needed for frontends that did not support http fetch, and is not needed with Fusebox.
Changelog: [General][Changed] `Debugger.scriptParsed` now includes the field `sourceMapURL` as a (rewritten) remote url as opposed to base64 data url
Reviewed By: robhogan
Differential Revision: D68708899
fbshipit-source-id: 95242582c79ce4e9a573d4a3e639b0dc3290869e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48975
After cutting 0.78-stable, we need to bump the monorepo packages to `0.79.0-main`
## Changelog:
[Internal] - Bump monorepo packages to `0.79.0-main`
Reviewed By: cortinico, huntie
Differential Revision: D68715005
fbshipit-source-id: cb5abbf05e8638683687be8d61d66b3037111572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47968
Updates the Inspector Proxy to report + log when a profiling build target (experimental) is registered. This notifies the developer that debugging is available for these app(s), which will not otherwise fetch development bundles from Metro.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66501771
fbshipit-source-id: e06dee279158094ad5c70bf8e6a90e7c983de48a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47880
The previous diffs in this stack have aimed to make URL rewriting by inspector-proxy robust to any configuration of device->server, debugger->server and server->server connections.
Though rewriting was originally introduced to support Android emulator networking, we can now expand it to cover other use cases, like the device reaching the server over an internet address not reachable from the dev machine, or the debugger routing to the server through a tunnel on a different port, without needing CORS workarounds.
Changelog
[General][Fixed] dev-middleware: Rewrite URLs in the inspector proxy to cover all configurations, not just Android emulators.
Reviewed By: huntie
Differential Revision: D66247355
fbshipit-source-id: e9201ebc1f7f5fe2119c71cd4d7b4ca895645404
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47876
Currently, if a device is connected to the bundler via, say, `http://10.0.2.2:8081` (Android default), and a debugger is opened on `http://localhost:8081`, we rewrite hostnames `10.0.2.2.`<->`localhost` so that URLs are correct relative to each.
However, if the debugger is on a different port or protocol, this breaks down - because we only rewrite hostnames.
This fixes that by using the debugger's connecting `Host` header and `encrypted` state to derive the base URL of the server relative to the frontend. We then update the rewriting logic to use this actual full origin (protocol + host) in place of the device-relative origin.
Changelog:
[General][Fixed] dev-middleware: Fix URL rewriting where device and debugger reach the server on different ports/protocols.
Reviewed By: huntie
Differential Revision: D66077627
fbshipit-source-id: 01f6565149caa34b1e9e50dd58deb0122485657c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47872
Largely a refactoring to the way we currently rewrite `url`/`urlRegex` in `Debugger.setBreakpointByURL` CDP requests (debugger->target).
Rewriting regexes is fragile, it only really works if we can assume `'localhost'` appears literally and that ports and protocols don't need changing. The intention here is to freeze the current behaviour so as not to break anyone relying on it (if anyone is), and decouple it from more robust rewriting we want to generalise.
Also adds simple regex escaping to host names (always IPv4 addresses) we inject into regex patterns, since the previous approach could've led to false matches in unlikely edge cases.
Changelog:
[General][Fixed] dev-middleware: Regex-escape IP addresses in urlRegex replacements
Reviewed By: huntie
Differential Revision: D66238782
fbshipit-source-id: 4cd0029081d68c193e36d3713057ffdc7ef0656f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47685
Currently, we assume any URL with a hostname of `10.0.2.2` or `10.0.3.2` (device-relative) is eligible for rewriting to `localhost` (frontend-relative), because we assume the device is an Android emulator. We rewrite these URLs between device and dev machine so that the rewritten URLs are reachable from the dev machine.
This diff narrows this logic so that we'll only rewrite URLs where the hostname matches the pre-existing list *and* this matches the host the device is actually connected on, according to its headers from the original connection.
The main motivation for this change is to unblock removing assumptions about device-reachable vs server-reachable hosts. Later in the stack we'll drop the hardcoded listing of `10.0.2.2` etc in favour of identifying URLs that target the dev server, from whatever network.
There's also an edge case fix here that `10.0.2.2` etc might actually refer to a remote LAN server, and not be an Android emulator's alias for for an emulator host.
Changelog:
[General][Fixed] RN DevTools: Don't assume 10.0.2.2 is an alias for localhost unless it's used to establish a connection to the server
Reviewed By: huntie
Differential Revision: D66058704
fbshipit-source-id: bad28717b0c9b1ca43e2ea3391cef13f87892e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47653
## Context
Currently, when `nativeSourceCodeFetching == false`, `inspector-proxy` attempts to pre-fetch source maps, given the URL from a `Debugger.scriptParsed` event, and embeds them into `Debugger.scriptParsed`'s `sourceMapURL` using a data URI.
This was originally to support frontends that did not perform HTTP requests or were blocked (eg by CORS), but we're retaining it for the moment because it's more performant than lazy loading the source map.
Similarly, we perform middleware->server fetches to respond to `Debugger.getScriptSource` events.
To make these fetches for URLs that target `10.0.2.2` (ie, addressable from within an Android emulator) (etc), we rewrite `10.0.2.2`->`localhost` and perform a `fetch` from the Node process running dev-middleware.
## The problem
Consider a setup where:
- Metro is running on a remote server, listening on `8081`.
- Dev machine tunnels `localhost:8082` -> remote `8081`.
- An app is running on an Android emulator on the dev machine, with bundle URL configured to `10.0.2.2:8082`.
In this case, we'll rewrite `10.0.2.2:8082` to `localhost:8082`, which *is* reachable and correct from the dev machine, but *not* from the machine where Metro is running, so the `fetch` of a source map from the inspector proxy will fail.
## Motivation
This might seem like a niche case, but it's part of fixing a series of unsafe assumptions that currently prevent us from running DevTools on an arbitrary port.
## This fix
Preserve the current behaviour (simple `10.0.2.2`<=>`localhost`) for URLs sent to the frontend, but construct a separate, server-relative URL, using the configured `serverBaseUrl`, for `fetch` calls within dev-middleware.
Changelog:
[General][Fixed] RN DevTools: Fix fetching sources and source maps when the dev-server is remote and not tunnelled via the same port+protocol.
Reviewed By: huntie
Differential Revision: D65993910
fbshipit-source-id: a0cdcf1644e97a2af3d8583f2da2aaa51276f68c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47675
Use `request` over `fetch` in `dev-middleware`'s tests.
This is required by the next diff in the stack to spoof the `Host` header for testing purposes, which isn't permitted by the `fetch` spec.
The return type is a bit different (eg `statusCode` vs `status`, no `ok` prop), but the modifications needed are pretty straightforward.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D66005427
fbshipit-source-id: f311b0188d6d0ec220a037774fca78df5373163a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47628
`serverBaseUrl` is currently documented as:
> The base URL to the dev server, as addressible from the local developer machine
This is problematic in general because `dev-middleware` on a server doesn't necessarily know about where clients might be reaching it from, how tunnels or port-forwards are set up, etc., and this can change over the lifetime of the server and vary between clients.
Indeed, our own use of `serverBaseUrl` from both `community-cli-plugin` and internally simply sets it to the host and port the dev server is listening on - ie it's the address of the dev server accessible *from the server*.
This PR changes the docs, redefining `serverBaseUrl`, to match the way we currently specify it.
One usage where we *do* want the previously documented behaviour is in responses to `/json/list` (`getPageDescriptions`) where the URLs in the response should be reachable by a browser requesting `/json/list`.
Here, we use the request (host header, etc.) to attempt to get working base URL.
History:
It should be mentioned that this is the latest in a series of changes like this:
- https://github.com/facebook/react-native/pull/39394
- https://github.com/facebook/react-native/pull/39456
Learning from those:
- This change does *not* break Android emulators, which routes `10.0.2.2` to localhost, or other routed devices, because `/open-debugger` still uses server-relative URLs, and now formally delegates to `BrowserLauncher` to decide what to do with those URLs (internally, VSCode / `xdg-open` handles port forwarding)
- Middleware configuration is no longer required to specify how it is reachable from clients.
This sets up some subsequent changes for more robust handling of tunnelled connections.
Changelog:
[General][Breaking] dev-middleware: Frameworks should specify `serverBaseUrl` relative to the middleware host.
Reviewed By: huntie
Differential Revision: D65974487
fbshipit-source-id: 1face8fc7715df387f75b329e80932d8543ee419
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47652
## Background
When the `nativeSourceCodeFetching` capability is disabled, `inspector-proxy` rewrites URLs exchanged over CDP between device and frontend so that URLs are addressable from CDT - in particular, when using an Android emulator `10.0.2.2` (host's address from within the emulator) is rewritten to and from `localhost` (the equivalent address reachable from the host).
Previously - before we implemented `Network.loadNetworkResource`, or on old frontends that don't attempt to use that method - this worked reasonably well. A `fetch` from CDT to Metro would succeed on the rewritten URL.
## Problem
Since we implemented `Network.loadNetworkResource`, but disabled the `nativeSourceCodeFetching` capability, source fetching is broken under Android emulators. We're rewriting URLs to be frontend-relative, but then attempting to fetch them through the device, because as far as CDT is aware, `Network.loadNetworkResource` should still be tried first.
When `Network.loadNetworkResource` responds with a CDP *error*, CDT falls back to a local fetch (which would work), but when it responds with a CDP *result* of `success: false`, there is no fallback.
## Fix
This diff adds an interception guarded behind `nativeSourceCodeFetching == false`, which rejects any calls to `Network.loadNetworkResource` with a CDP error. This restores the previous behaviour from before `Network.loadNetworkResource` was implemented at all.
NOTE: An alternative approach would be to rewrite URLs back to device-relative for `Network.loadNetworkResource`, but IMO it's more correct for the frontend to respect that the device is asserting that it doesn't have that capability, and not to try to use it.
Changelog:
[Android][Fixed] RN DevTools: Fix source loading when using an Android emulator connecting to a dev server on the host.
Reviewed By: huntie
Differential Revision: D66074731
fbshipit-source-id: f2050c014cd5cfa546bff5e9d0412413a5daff35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47120
Fixes no-op behaviour of the "Open DevTools" Dev Menu item (bug on `main` introduced with D63329456).
This was caused by a change to the `description` field contents in our CDP `/json/list` response, when under Fusebox. In the `/open-debugger` call from the Dev Menu, we were still using the older `appId` param.
This did not affect `j` to debug, which uses the `target` param.
{F1937186832}
Changes:
In short: Matching against the `description` string is now fully eliminated for modern debugger targets.
- Update native Dev Menu implementation to omit `appId` parameter (`device` param alone is sufficient and fully precise on these platforms).
- Update `/open-debugger` implementation to ignore the `appId` parameter for modern targets, and document this in the `dev-middleware` README.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D64597581
fbshipit-source-id: 46f536e7d0a4ececab0d52f4c0704e8698466cd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47109
Fixes the `lint/sort-imports` errors that are now surfaced after fixing the lint configuration.
For a couple files, I added lint suppressions instead because the unsorted import ordering is important due to interleaved calls with side effects.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D64569485
fbshipit-source-id: 26415d792e2b9efe08c05d1436f723faae549882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47098
Changelog: [Internal]
D63329456 updated the `description` field to be human-readable.
Unfortunately, InspectorProxy relies on this field to compare the incoming `/open-debugger` calls.
hoxyq discovered the symptom of Fusebox failing to launch with `No compatible apps connected. React Native DevTools can only be used with the Hermes engine.` in Metro
Reviewed By: hoxyq
Differential Revision: D64547367
fbshipit-source-id: deed6851f3ede2c74be2b492def1eba6e58c43e6
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## 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
-->
[GENERAL] [FIXED] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46780
This is primarily a debugger server change to better-align the `title` and `description` fields (visible in via the CDP `/json/list` endpoint), reporting them directly from the device.
For React Native users, the net effect of this change is to improve/align the display name for each debugger target in the CLI multi-select menu (`j` to debug). This change may also be useful for discovery in non-Fusebox frontends such as VS Code (`vscode-expo` extension).
Changes:
- Rename `title` prop on `InspectorPageDescription`/`IInspector::addPage` to `description` (no call site changes).
- Add `deviceName` param to `InspectorPackagerConnection`.
- Move the page `description` to the `description` JSON field.
- Update `InspectorPackagerConnection::Impl::pages()` to return new `title` and `description` fields.
- Align `OpenDebuggerKeyboardHandler` to display `title` field.
- Deprecate the nonstandard `deviceName` field.
**Before**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "React Native Bridgeless [C++ connection]",
"description": "com.facebook.RNTester",
...
}
```
The `description` field was previously the closest thing we had to a target identifier. Today, this is not needed, since we have the stable `reactNative.logicalDeviceId` field.
**After**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "com.facebook.RNTester (iPhone 16 Pro)",
"description": "React Native Bridgeless [C++ connection]",
...
}
```
The `title` field is now more human readable and aligned with what we render in the window title of React Native DevTools. The `description` field describes the type of debugger target (the specific React Native implementation).
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D63329456
fbshipit-source-id: cfe98f77e31c729431005925cfc66e2780ef8c72
Summary:
This change bumps the React Native version in main to 0.77
bypass-github-export-checks
## Changelog:
[General][Changed] - Bump main to 0.77-main
## Facebook:
generated by running `js1 publish react-native 0.77.0-main`
Reviewed By: cortinico
Differential Revision: D62575939
fbshipit-source-id: 6d239fca2eed6cfe51f8c37f78d8dc8730c18b8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46302
Changelog:
[General][Fixed] - Removed noisy ENOENT error message upon launching the debugger
As described in T200199544, Metro terminal in open-source would show an error message for the missing embedder script.
In this diff, we add a response of an empty file to open-source (no-op)
Reviewed By: hoxyq
Differential Revision: D62103015
fbshipit-source-id: 219bc398b7786527db00528cca175adc13a527a0
Vitali Zaidman
Alex Hunt
Rubén Norte
Phil Pluckthun
Tommy Nguyen
Riccardo Cipolleschi
Andrew Datsenko
Rob Hogan
Nicola Corti
Tim Yung
Edmond Chui
Cedric van Putten