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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46231
Removes this option from `npx react-native start`. Flipper will no longer be the default launch flow in 0.76.
The debugger frontend variant remains controlled by `target.reactNative.capabilities?.prefersFuseboxFrontend`. This will always be Fusebox, since D60893243.
Changelog:
[General][Changed] Remove `--experimental-debugger` option from start command
Reviewed By: robhogan
Differential Revision: D61852415
fbshipit-source-id: 3351f0e12c24717916a70dd1ea28f8690bb5509f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45138
Add a new `/open-debugger` endpoint format that allows specifying `target` - the proxy-unique target `id`. This is logically equivalent to specifying both device and page.
Changelog:
[General][Added]: Inspector: Support `/open-debugger` specifying `target` param
Reviewed By: hoxyq
Differential Revision: D58950622
fbshipit-source-id: 9665f8a24ba2bb0561cc3c693dfb84bfffdeb4a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45140
Previously, if the `/open-debugger` endpoint was provided with both `device` and `appId` query params, we would:
- Try to find a target with a matching `device` (note that these logical "devices" are unique per-app) - if found, use it. Otherwise,
- Try to find a target with a matching `appId` - if found, use that.
This could go "wrong" in two ways:
- If a `device` is given with a spurious `appId`, we'd open to a target with an `appId` differing from the one specified.
- If the `device` has gone away but there is a different target with the same app, we'd use that as a fallback (right app, wrong device).
This applies the filters more strictly so that if both are given, both must match.
Changelog:
[General][Changed]: Inspector: Enforce device and appId filters if both are given to /open-debugger
Reviewed By: hoxyq
Differential Revision: D58951952
fbshipit-source-id: a95f1160e5c88f957445058f3273e922a5d28c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45060
Currently, `j`, (i.e., `/open-debugger` with no parameters), connects the "first available" target, which in practice is the first page of the first connected device still connected.
In the absence of a target selection UI, a better guess at user intent is to use the *latest* target (most recently added page of most recently connected device).
Also slightly reduces CLI noise by not claiming that we're launching a debugger when there's no target, and not qualifying which target when there's only one.
Changelog:
[General][Changed] Debugger: `j` opens most recent (not first) target.
Reviewed By: huntie
Differential Revision: D58736151
fbshipit-source-id: 3d106a1fa958f9e5c91b16e04075609e1abf6e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45069
Currently, `/json/list` returns pages within each device in the iteration order of a C++ `unordered_map`, which doesn't tell us anything useful. Page IDs happen to be sequential, but only as an implementation detail.
Change this contract so that we guarantee ordering reflects addition order, allowing clients to consistently select e.g. most recently added page for a given device.
The implementation of this is as simple as switching from an `unordered_map` to a key-ordered`map`, because we already assign keys (page IDs) with an incrementing integer. Within the inspector proxy, devices already use an insertion (connection)-ordered JS `Map`, so we just document this guarantee.
Changelog:
[General][Changed] Debugger: Make `/json/list` return connection-addition-ordered targets.
Reviewed By: huntie
Differential Revision: D58735947
fbshipit-source-id: 7a132cc5e750475792a2b845afc9a42424690bf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45035
Changelog: [General][Fixed] Avoid a zombie state when opening a second debugger frontend concurrently.
The problem here was that we were sending proxy-protocol messages to the device in the wrong order (`disconnect` *after* `connect`):
{F1701266597}
The root cause was that we were depending on the outgoing debugger socket's async `close` event to trigger sending the `disconnect` message to the device. This would happen after we'd already (synchronously) sent the `connect` message.
With this diff, we send the `disconnect` message synchronously with calling `close()` on the debugger socket, which fixes the ordering problem at the source. To avoid sending duplicate `disconnect` messages (e.g. one before calling `close()` and one from the `close` event handler), we store some extra state on `Device` (`#connectedPageIds`).
Reviewed By: robhogan, huntie
Differential Revision: D58730634
fbshipit-source-id: 0f54af2e4f8071a8f6d97cc9e3d8a4ea89a46f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45027
Changelog: [Internal]
Changes the device ID collision handling logic to reuse `Device` instances instead of creating new ones. This enables further refactoring of `Device` to improve session state isolation.
Reviewed By: hoxyq
Differential Revision: D58724884
fbshipit-source-id: bc11ce45ce8c80c58c32dcd1b07b28f1d1753a62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45011
Changelog: [Internal]
Fixes an inspector-proxy test case that was (silently) incorrect. This is in preparation for an upcoming rewrite of the core of inspector-proxy to more strictly isolate session state, which causes the incorrect test to fail.
Reviewed By: hoxyq
Differential Revision: D58193527
fbshipit-source-id: bdc27179210117ca9249b272f2e4aff19ba8a06c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45010
D46482492 added logic for handing off state across "device" connections that have the same ID. This logic currently has no test coverage. It also contains a bug whereby the new device's pages are removed from the target listing endpoint (`/json`) when the *old* device's socket is closed.
This diff adds tests and fixes the bug.
Changelog: [General][Fixed] inspector-proxy no longer accidentally detaches connected devices.
## Next steps
It seems that the device ID handoff logic exists to paper over a deeper problem with the inspector proxy protocol (or its implementation in React Native): The React Native runtime should not routinely be creating new "device" connections without tearing down previous ones.
In followup diffs, I'll explore changing this behaviour for Fusebox, based on the new test coverage.
Reviewed By: robhogan
Differential Revision: D51013056
fbshipit-source-id: e0c17678cc747366a3b75cef18ca2a722fc93acd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44811
Changelog:
[General][Fixed] - Debugger frontend socket-termination countdown now begins after the ping message is actually sent
The debugger is currently disconnected if a ping-pong message is missed.
This causes the debugger to be unusable if it happens to be lagging, e.g. when the initialisation is competing with the flood of log spam T191394188
There are a few ways to fix this as discused with motiz88 and robhogan:
1. Ensure the websocket has a chance to respond, e.g. in via web worker
1. Lengthen the time allowed for the pong resopnse
I've done some digging to find the root cause of the UI being blocked in CDT, However, profiling shows that most of the work is not simple to break up, i.e. the number of expensive re-layout calls. Diving into that rabbit hole could mean accidentally writing React.
Because we ping every 10 seconds, we could get un/lucky where CDT happens to be busy _at that exact moment_, making this a flaky symptom to fix, even if we lengthen the allowed time-to-respond.
# V2+
So upon further investigation, CDT websocket is actually responding to the pings in due time:
{F1679132204}
(CDT doesn't show the ping/pong API as frames, so a custom tick/tock message was used to visualise the timing)
Over here in dev-middleware, we currently start a timeout to terminate the socket after sending the ping:
https://www.internalfb.com/code/fbsource/[813870db697a8701f2512d25a7fed730f0ec6ed9]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/InspectorProxy.js?lines=306-307
If CDT doesn't respond in time, websocket would be terminated.
But we saw CDT respond immediately above, even during the log spam, so the delay must be coming from somewhere else.
The intuition is that during the log-spam, the middleware takes a perf hit too when it's processing the spam from the device and forwarding it to the CDT websocket.
We can confirm this by passing a "sent" callback via `socket.ping(cb)`:
9bdb58070d/lib/websocket.js (L246-L254)
This gives us the timing between calling `socket.ping()` and when the ping is actually sent.
Regular, stress-free operation without log-spam shows most pings are sent within the same millisecond:
{F1679223326}
With the pong response grace period at 5 seconds, there's plenty of time for CDT to `pong` back. That's why it has been working in most cases.
However, during the log-spam, we easily see this send-sent delay over 5 seconds. In extreme cases, almost 30 seconds would have passed before middleware sent a message to CDT, which then responded under 2 seconds:
{F1679163335}
This means while CDT is getting flooded and has observable lag in the UI, the smoking gun is actually the middleware.
Digging a little deeper, we know that incoming messages from the target goes into a Promise queue, including the console logs:
https://www.internalfb.com/code/fbsource/[d5d312082e9c]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/Device.js?lines=155-157
This means during the flood of logs from the target, the Promise queue keeps getting chained rapidly for each message.
Meanhile, the `ws` lib uses the underlying NodeJS `Socket.write` method for `ping(…)` and `send(…)`:
9bdb58070d/lib/sender.js (L349)
…which is guaranteed to fire the callback asynchronously:
https://github.com/nodejs/help/issues/1504#issuecomment-422879594
Promise queue is in the macro task queue, which gets priority before the micro task queue. So if the Promise queue is not cleared yet, the websocket queue will have a hard time getting executed in time – explaining the extreme send-sent durations during a log spam.
The fix is simple:
1. Start the terminate-socket-timer until the `ping` is actually sent
1. Treat any incoming message (along with `pong`s) as a terminate-socket-timer reset
1. This also applies if `pong` comes in between `send` and `sent`, which can happen sometimes due to the async nature of the callback:
{F1679288626}
# V1
~~In this diff, a more forgiving mechanism is introduced, i.e. CDT is allowed to miss a ping-pong roundtrip 3 times before the websocket connection is terminated.~~
~~This allows a bit more breathing room for CDT's initialisation during log spam while maintaining the same ping-pong interval for VS Code to keep the auto SSH tunnel alive.~~
Reviewed By: huntie
Differential Revision: D58220230
fbshipit-source-id: 7111c9878492d8755a6110a5cdf4ef622265001d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44835
As titled. The `vm` field is not part of the CDP spec and will not be used by the modern debugger frontend or proxy.
This change affects modern CDP targets only (using `InspectorPackagerConnection`). We aim to enable sharing of more detailed metadata over 1/ a new, dedicated CDP domain, and 2/ namespaced under the existing `reactNative` field (for the latter, strictly limited to metadata necessary for dev server functionality).
Changelog: [Internal]
(Note: `/json` endpoint behaviour is unchanged for legacy CDP targets)
Reviewed By: robhogan
Differential Revision: D58285587
fbshipit-source-id: dfef3a56b20486ba11891df9940f6c7bef59528e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44672
Swaps out and simplifies the internals of the debugger launch flow.
We observed that we could achieve better launch/windowing behaviour by passing the `--app` argument directly to the detected Chrome path.
This shares the user's default Chrome profile:
- Fixes unwanted behaviour such as a separate dock icon on macOS (which, when clicked, would launch an unwanted empty window).
- Enables settings persistence.
This change also removes the `LaunchedBrowser.kill` API.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57726649
fbshipit-source-id: fc3a715dc852a50559048d1d1c378f64aeb2013f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44638
Reverts the debugger launch flow to use the default `ChromeLauncher` profile. This is the approach used in the current `--experimental-debugger` experiment and by Expo.
This is motivated after a review of the tradeoffs of a guest profile — which allow us to programatically quit the browser process, however takes over system URL handling.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57619542
fbshipit-source-id: 3713e1cf8eed61e7a70ed1e4eb58f02da845155f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44499
Changelog: [internal]
As [discussed](https://fb.workplace.com/groups/react.devx.team/permalink/930483712103526/), we'll begin segmenting Telemetry signals by Fusebox/non-Fusebox.
* Add new flag in event reporter for `debugger_command` (other events in subsequent diffs)
* Add new column to the Scuba destination
Reviewed By: blakef
Differential Revision: D57140479
fbshipit-source-id: 7ea813b1b4d53a282873fa95c8ee82e5d6f3d1d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44498
Changelog: [internal]
Quick refactor to reduce commit noise in the following diff in the stack
Reviewed By: blakef
Differential Revision: D57140480
fbshipit-source-id: aa1fef83d5347b8a11651d3d5c4112b4adf7a7d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44362
Packages that are built and directly run in the monorepo no longer need to worry about
conditionally registering themselves to transpile Flow -> JS at runtime. Our build step
strips this file now.
Changelog: [Internal] changes in published packages no longer require conditional calls to Babel register.
Reviewed By: huntie
Differential Revision: D56839521
fbshipit-source-id: 6bec706c639f1ab4138e0b790be8a07654333046
Summary: Changelog: [General][Removed] `launchId` query param for `/debugger-frontend` is no longer generated automatically for each `/open-debugger` call. Caller of `/open-debugger` is now responsible for generating the `launchId`, which will be passed along to `/debugger-frontend`.
Reviewed By: robhogan
Differential Revision: D55164645
fbshipit-source-id: b83303eda77b6fb86ebf50f699d9f308676533c6
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44180
Changelog: [General][Changed] Update Chrome launch flags for `--experimental-debugger` launch flow
Internally at Meta, we've been testing the experimental debugger launch flow with a different set of Chrome flags than are currently shipped in open source. This diff fixes those differences:
* Removes `--disable-backgrounding-occluded-windows`
* Adds `--guest`
Reviewed By: EdmondChuiHW
Differential Revision: D56418271
fbshipit-source-id: 884c5746e93cad89f17e4ef9e3ef193a2a454eb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44092
In a setup where a device retrieves a bundle from `http://127.0.0.1:8081`, but this is tunnelled to a remote host with only an IPv6 stack (eg, FB dev servers), the host running the inspector-proxy will fail to fetch source or source maps from 127.0.0.1 despite typically being on the same host (indeed, process) as Metro.
This causes a surprising inconsistency where using a bundler URL of `localhost` from the device results in source maps being inlined into `Debugger.scriptParsed`, but using a bundler URL of `127.0.0.1` causes inspector-proxy to fall back to preserving URLs, which are typically fetched lazily by CDT later.
This should be unnecessary once we've implemented CDP `Network.loadNetworkResource` and removed `Debugger.scriptParsed` rewriting, but for now it brings IPv6 tunnelled servers in line with local servers.
Changelog:
[General][Changed] Inspector proxy: Rewrite 127.0.0.1 to localhost in source map URLs for better IPv4->IPv6 tunnelling support.
Reviewed By: motiz88
Differential Revision: D56138742
fbshipit-source-id: b65c9cc8225a0ed54cf32171f640ef9e6408c762
