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:
This is a proposal for the `react-native/dev-middleware` package, to allow implementers to extend the CDP capabilities of the `InspectorProxy`. It's unfortunately needed until we can move to the native Hermes CDP layer.
At Expo, we extend the CDP capabilities of this `InspectorProxy` by injecting functionality on the device level. This proposed API does the same, but without having to overwrite internal functions of both the `InspectorProxy` and `InspectorDevice`.
A good example of this is the network inspector's capabilities. This currently works through the inspection proxy, and roughly like:
- Handle any incoming `Expo(Network.receivedResponseBody)` from the _**device**_, store it, and stop event from propagating
- Handle the incoming `Network.getResponseBody` from the _**debugger**_, return the data, and stop event from propagating.
This API brings back that capability in a more structured way.
## API:
```ts
import { createDevMiddleware } from 'react-native/dev-middleware';
const { middleware, websocketEndpoints } = createDevMiddleware({
unstable_customInspectorMessageHandler: ({ page, deviceInfo, debuggerInfo }) => {
// Do not enable handler for page other than "SOMETHING", or for vscode debugging
// Can also include `page.capabilities` to determine if handler is required
if (page.title !== 'SOMETHING' || debuggerInfo.userAgent?.includes('vscode')) {
return null;
}
return {
handleDeviceMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
handleDebuggerMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
};
},
});
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Add inspector proxy device message middleware API
Pull Request resolved: https://github.com/facebook/react-native/pull/43291
Test Plan: See added tests and code above
Reviewed By: huntie
Differential Revision: D54804503
Pulled By: motiz88
fbshipit-source-id: ae918dcd5b7e76d3fb31db4c84717567ae60fa96
Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.
The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.
As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.
## Changelog:
[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`
Pull Request resolved: https://github.com/facebook/react-native/pull/41370
Test Plan: N / A
Reviewed By: robhogan
Differential Revision: D51163134
Pulled By: blakef
fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283
Summary:
Expose a `unstable_browserLauncher` option to `createDevMiddleware()`. This allows integrators to provide a custom implementation for opening URLs in a web browser, initially a `launchDebuggerAppWindow` method.
Customising the browser launcher implementation can be useful in cases where the dev server is running remotely and not on the developer's local machine.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48647750
fbshipit-source-id: ebf34106ad27899024396b13b22ec4536aad05b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39091
Changelog: [Internal]
Adds a simple typed logging hook to `react-native/dev-middleware`. This is intended to allow integrators to receive events from the dev server, apply any relevant sampling/processing, and log them to a backend. (To be clear, the open source version of React Native does not and will not collect any data.)
WARNING: The API will evolve over the coming weeks/months and is *not guaranteed to be stable* - it might even break between patch releases.
Reviewed By: huntie
Differential Revision: D48466760
fbshipit-source-id: ed1e21fb0dac5d6199ff1ee26017a1d33d9b7d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39045
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
- Relocates `metro-inspector-proxy` source from the Metro repo into the React Native repo as part of the `react-native/dev-middleware` package.
- Drops the `runInspectorProxy` entry point.
- Attaches the Inspector Proxy to the `createDevMiddleware()` API as the new integration point for this functionality.
- Documents migrated endpoints + usage of `createDevMiddleware()` in README.
Changelog: [Internal]
Metro changelog: None (`metro-inspector-proxy` is now an internal component of `react-native`, covered in the [release notes for 0.78.1](https://github.com/facebook/metro/releases/tag/v0.78.1))
Reviewed By: motiz88, blakef
Differential Revision: D48066213
fbshipit-source-id: 3fbef5d881f6f451cb5955dcbbc362c53347437e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38718
> NOTE: Replaces https://github.com/facebook/react-native/pull/38240
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
To support incoming new React Native packages around debugging (including migrating over [`react-native-community/cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro)) — which target Node.js and require a build step, this PR adds a minimal shared build setup across the `react-native` monorepo.
The setup is closely inspired/based on the build scripts in Jest, Metro, and React Native CLI — and is a simple set of script wrappers around Babel. These are available as build commands at the root of the repo:
- `yarn build` — Builds all configured packages. Functionally, this:
- Outputs a `dist/` directory with built files.
- Rewrites package.json `"exports"` to update every `./src/*` reference to `./dist/*` (source of truth).
- `scripts/build/babel-register.js` — Allows running all Node.js entry points from source, similar to the current setup in [facebook/metro](https://github.com/facebook/metro). (Example entry point file in this PR: `packages/dev-middleware/src/index.js`)
Build configuration (i.e. Babel config) is shared as a set standard across the monorepo, and **packages are opted-in to requiring a build**, configured in `scripts/build.config.js`.
```
const buildConfig /*: BuildConfig */ = {
// The packages to include for build and their build options
packages: {
'dev-middleware': {target: 'node'},
},
};
```
For now, there is a single `target: 'node'` option — this is necessary as `react-native`, unlike the above other projects, is a repository with packages targeting several runtimes. We may, in future, introduce a build step for other, non-Node, packages — which may be useful for things such as auto-generated TypeScript definitions.
{F1043312771}
**Differences from the Metro setup**
- References (and compiles out) repo-local `scripts/build/babel-register.js` — removing need for an npm-published dependency.
## Current integration points
- **CircleCI** — `yarn build` is added to the `build_npm_package` and `find_and_publish_bumped_packages` jobs.
**New Node.js package(s) are not load bearing quite yet**: There are not yet any built packages added to the dependencies of `packages/react-native/`, so this will be further tested in a later PR (and is actively being done in an internal commit stack).
### Alternative designs
**Per-package config file**
Replace `scripts/build/config.js` with a package-defined key in in `package.json`, similar to Jest's [`publishConfig`](https://github.com/jestjs/jest/blob/1f019afdcdfc54a6664908bb45f343db4e3d0848/packages/jest-cli/package.json#L87C3-L89C4).
```
"buildConfig": {
"type": "node"
},
```
This would be the only customisation required, with a single Babel config still standardised. Another option this might receive in future is `enableTypeScriptCodgeen`.
**Rollup**
More sophisticated build tool for Node.js, used by the React codebase (albeit within a custom script setup as well).
**Lerna and Nx**
- Most sophisticated setup enabling caching and optimised cloud runs.
- Probably the most likely thing we'll move towards at a later stage.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D47760330
fbshipit-source-id: 38ec94708ce3d9946a197d80885781e9707c5841
Tim Yung
Alex Hunt
Cedric van Putten
Gabriel Donadel
Moti Zilberman