mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
@simek/fix-cpp-docs-comments
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Cedric van PuttenandFacebook GitHub Bot
|
32fe244744 |
fix(react-native): pass the protocol from bundle URL to HMR client on Android (#48998)
Summary: This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184): ``` java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup ``` This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS. The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds. <details><summary>Alternative workaround</summary> See [this change](https://github.com/facebook/react-native/compare/main...byCedric:react-native:patch-2). <img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" /> </details> See full explanation on https://github.com/facebook/react-native/issues/48970 > We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android. > >- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file. >- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules /RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file. > >Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`). > >This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client. ## Changelog: [ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android <!-- 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 Pull Request resolved: https://github.com/facebook/react-native/pull/48998 Test Plan: See full explanation on https://github.com/facebook/react-native/issues/48970 > It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests. > >You can set this up through: >- `bun create expo@latest ./test-app` >- `cd ./test-app` >- `touch .env` >- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env** >- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env** >- `bun run start` > >Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through: > >```bash >curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url >``` > >This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`. Reviewed By: cortinico Differential Revision: D68768351 Pulled By: javache fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
ba894c908a |
fix(react-native): pass the protocol from bundle URL to HMR client on Android (#48970)
Summary:
We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue.
This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48970
Test Plan: It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
Reviewed By: fabriziocucci
Differential Revision: D68711137
Pulled By: javache
fbshipit-source-id: 230c1c91c8189c0a109d20defe085966ac8f5721
|
||
|
Cedric van PuttenandFacebook GitHub Bot
|
eeb6122f39 |
fix(dev-middleware): respond with status code 200 when launching RNDT (#46814)
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 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
39c98fb8f8 |
fix(react-native-codegen): upgrade jscodeshift@17.0.0 to resolve outdated dependencies (#46724)
Summary: This upgrades `jscodeshift` from `0.14.0` to `17.0.0`, to resolve unsupported babel dependencies when installing React Native. See https://github.com/expo/expo/issues/31613 ## Changelog: [GENERAL] [FIXED] - Upgrade Codegen dependency `jscodeshift@17.0.0` to resolve outdated dependencies Pull Request resolved: https://github.com/facebook/react-native/pull/46724 Test Plan: To test it out yourself: - `npx create-expo@latest ./test-codegen` - `cd ./test-codegen` - `npm why babel/plugin-proposal-nullish-coalescing-operator@7.18.6 | grep codegen` - [npm deprecation](https://www.npmjs.com/package/babel/plugin-proposal-nullish-coalescing-operator/v/7.18.6) - `npm why babel/plugin-proposal-class-properties@7.18.6 | grep codegen` - [npm deprecation](https://www.npmjs.com/package/babel/plugin-proposal-class-properties/v/7.18.6) - `npm why rimraf@2.6.3 | grep codegen` - [npm deprecation](https://www.npmjs.com/package/rimraf/v/2.6.3) - `npm why babel/plugin-proposal-optional-chaining@7.21.0 | grep codegen` - [npm deprecation](https://www.npmjs.com/package/babel/plugin-proposal-optional-chaining/v/7.21.0) > [!IMPORTANT] > There are other dependencies that require an update, unfortunately there are no flow typings available (yet). > - `npm why glob@7.2.3 | grep codegen` - [npm deprecation](https://www.npmjs.com/package/glob/v/7.2.3) Reviewed By: cortinico Differential Revision: D63629133 Pulled By: huntie fbshipit-source-id: 3799e49677b8e5fd64841e6c7f855bde10e15072 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
30a3e6e8df |
refactor(dev-middleware): drop node-fetch in favor of Node built-in fetch (#45227)
Summary: Node 22 doesn't work well with `node-fetch@2`, as one of their polyfills is using the deprecated `punycode` module. This causes unnecessary warnings like: <img width="986" alt="image" src="https://github.com/facebook/react-native/assets/1203991/13f66c5b-b6f4-4894-8576-ca9631d93f77"> Instead of upgrading to the [much larger `node-fetch@3`](https://packagephobia.com/result?p=node-fetch%403.3.2), this change drops `node-fetch` in favor of Node's own built-in `fetch` implementation (using [undici](https://github.com/nodejs/undici#readme)). > Note, `react-native/dev-middleware` [already has the `engines.node >= 18`](https://github.com/facebook/react-native/blob/c7988c9c82793b6b41d4c9190a28ce1202410fa0/packages/dev-middleware/package.json#L38-L40) (which is required for fetch). ## Changelog: [GENERAL] [CHANGED] - Drop `node-fetch` in favor of Node's built-in fetch from `undici` in `react-native/dev-middleware` <!-- 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 Pull Request resolved: https://github.com/facebook/react-native/pull/45227 Test Plan: See CI for passing tests Reviewed By: NickGerleman Differential Revision: D59202017 Pulled By: robhogan fbshipit-source-id: 15da5d5602e63958b8a3dc581dc1512649f16c12 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
652c74104a |
fix(dev-middleware): create custom message handler for synthetic page (#43559)
Summary: This is a follow-up bugfix for expo/expo#27425, related to: - https://github.com/facebook/react-native/issues/43291 - https://github.com/facebook/react-native/issues/43307 - https://github.com/facebook/react-native/issues/43310 - https://github.com/facebook/react-native/issues/43364 The middleware API works as intended and can run our extended CDP events. Unfortunately, this only applies to an actual `Page` from the device, not for the `React Native Experimental (Improved Chrome Reloads)` synthetic / virtual page. That's because the middleware instantiation gets aborted when the page can't be found in `this.#pages.get(pageId)`, which always returns `null` for this synthetic page. ## Changelog: [GENERAL] [FIXED] Create custom message handler for synthetic page Pull Request resolved: https://github.com/facebook/react-native/pull/43559 Test Plan: See added test case. Reviewed By: motiz88 Differential Revision: D55129412 Pulled By: huntie fbshipit-source-id: 9679d8fe68f3cb4104f4a042f93612b995baddc9 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
c62be78d99 |
feature(dev-middleware): use userAgent query parameter as fallback when header is unset (#43364)
Summary: At Expo, we use [Expo Tools](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts) to connect the [built-in vscode-js-debug](https://github.com/microsoft/vscode-js-debug) to Hermes. Since there are a few differences in vscode vs chrome devtools, we need to enable a couple of modifications through the [`customMessageHandler` API](https://github.com/facebook/react-native/pull/43291). Unfortunately, vscode itself doesn't set the `user-agent` header when connecting to the inspector proxy. Becuase of that, we'd need a fallback to "manually" mark the debugger as being vscode ([we use this query parameter here](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts#L208)). This PR supports setting the `user-agent` through `?userAgent=` when the header is not set. ## 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] [ADDED] - Fallback to query parameter based `user-agent` when header is unset Pull Request resolved: https://github.com/facebook/react-native/pull/43364 Test Plan: - Install [Expo Tools](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools) - Start Metro with this change. - Connect a device. - Run the vscode command `"Expo: Debug Expo app ..."` - Debugger should connect, and have it's user-agent marked as: `vscode/1.87.0 vscode-expo-tools/1.3.0` Reviewed By: huntie Differential Revision: D54804556 Pulled By: motiz88 fbshipit-source-id: 1ff558ba5350811ad042d08a713438e046759feb |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
3dee6d31b9 |
fix(dev-middleware): allow inspector proxy to fetch sourcemaps on lan connections (#43307)
Summary: The inspector proxy is inlining source maps on `Debugger.scriptParsed` CDP events. The inlining prevents Chrome DevTools from downloading this remotely, as that's not supported in newer versions anymore. The current implementation locks this inlining mechanism to just `localhost` and/or `127.0.0.1` addresses, making it incompatible with LAN or tunnel device connections. This PR removes that limitation to allow source map inlining on these LAN and tunnel connections. ## 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] Allow Inspector proxy to inline source maps on LAN connections Pull Request resolved: https://github.com/facebook/react-native/pull/43307 Test Plan: - See added test - Start Metro and connect a device over LAN, open the chrome devtools Reviewed By: huntie Differential Revision: D54485247 Pulled By: robhogan fbshipit-source-id: 6fcb0c6dd762d2f0a013497ba0a1126095b9130b |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
f3ce7cd76e |
feature(dev-middleware): add inspector proxy nativeNetworkInspection target capabilty flag (#43310)
Summary: This adds the `nativeNetworkInspection` target capability flag, to enable/disable the proxy-side network inspection handling. ## 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][ADDED] Add inspector proxy `nativeNetworkInspection` target capability flag Pull Request resolved: https://github.com/facebook/react-native/pull/43310 Test Plan: Once this lands, and is published through `react-native/dev-middleware`, we (Expo) can disable the proxy-side network inspection handling. See https://github.com/expo/expo/pull/27425/commits/1a1b601a29fbc5766628238db7259121689f6cd6 on PR expo/expo#27425 Reviewed By: christophpurrer, motiz88 Differential Revision: D54486516 Pulled By: huntie fbshipit-source-id: cc151349c816fb3866d3ec07af1a29a5f4ff9b00 |
||
|
Cedric van PuttenandFacebook GitHub Bot
|
a6397afb7f |
feat(cli): warn underlying command when using npx react-native init (#43127)
Summary: This adds a new warning for React Native 0.74, implementing the [RFC 0759](https://github.com/react-native-community/discussions-and-proposals/blob/nc/rnf/proposals/0759-react-native-frameworks.md#the-init-command) init command changes. - It's added inside `react-native/cli.js` to avoid warning users when actually executing `npx react-native-community/cli` commands. - The check is fairly simple: `process.argv[2] === 'init'`. The first two args are the Node bin and the actual script bin paths. - The message is sent over `console.warn` to avoid potentially mixing JSON with non-JSON output. ## Changelog: [GENERAL] [ADDED] - Warn with future command when using `npx react-native init` Pull Request resolved: https://github.com/facebook/react-native/pull/43127 Test Plan: Any command other than `init` must not warn. - `$ node ./path/to/react-native/cli.js init` - `$ node ./path/to/react-native/cli.js init --help` - Should warn with `Running: npx react-native-community/cli init`  - `$ node ./path/to/react-native/cli.js --help` - Must not warn  Reviewed By: cipolleschi Differential Revision: D54063131 Pulled By: cortinico fbshipit-source-id: c60b8b6034087b584e98b51f5bedf68a46caf44c |