Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42832
Various analogs to CSS types and utilities currently exist between `core` and `components/view`. These don't really belong well with either, so this adds a top-level "css" library, and moves `CSSTokenizer` there.
This is statically linked into Fabric binary on Android OSS.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D53377527
fbshipit-source-id: e2d3091ecb3533ecde4d0a08084369b4909532c3
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`.~~ (D53233914)
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`).~~ (D53233914)
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`. *← This diff*
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`. *← Also in this diff*
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53266707
fbshipit-source-id: e14867931d10e1739e6dab6dbd7d3386c685c3c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42432
Changelog: [internal]
This feature flag is accessed through `CoreFeatures` but it's initialized a few different ways:
* Android: assigned via `ReactFeatureFlags`, which is overridden by apps.
* iOS: `ReactNativeConfig` that's mapped to a dynamic configuration.
This migrates the flag to the new feature flag system.
Reviewed By: mdvacca, RSNara
Differential Revision: D52810065
fbshipit-source-id: d6fd1e819abbc4c3dee9e6221d8f99384f5197f5
Summary:
Changelog: [Internal] - `get-and-update-packages` was deleted in D53487874 also actually published the monorepo packages.
Update publish-npm to publish the updated nightly monorepo packages
Reviewed By: cipolleschi
Differential Revision: D53697621
fbshipit-source-id: 21facb49739ba64c43b921117356715be3d8868a
Summary:
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: cipolleschi
Differential Revision: D53710676
fbshipit-source-id: 667af4bcf7fa99563081330aa64d072faf50863b
Summary:
The recent change to make onDismiss work on Fabric broke the Modal on Paper (see [this comment](https://www.internalfb.com/diff/D52959996?dst_version_fbid=236415652884499&transaction_fbid=896066412296150)).
This change will fix that behavior.
The problem was that we were resetting the `isRendered` state only when the Modal receives the event from the Event emitter AND if it has the `onDismiss` callback set.
However, we should hide the component in any case if the ids match, and invoke the onDismiss if it is set.
## Changelog
[iOS][Fixed] - Make sure that Modal is dismissed correctly in Paper
Reviewed By: janeli-100005636499545
Differential Revision: D53686165
fbshipit-source-id: a1de0b29dca7c099e9fa0282ec80cae9a8fd6bc3
Summary:
RNGP now supports parsing the cxxModule field in codegenConfig and passes it over to codegen.
Changelog:
[Internal] [Changed] - Update RNGP to handle cxxModule in codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669912
fbshipit-source-id: 702f09ccf793f9205f0c8b54346c5d809695c35d
Summary:
This introduces the `cxxModule` field for RNTester where the local TM-CXX modules
are specified.
Changelog:
[Internal] [Changed] - Add cxxModule to RN-Tester's codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669913
fbshipit-source-id: 97b9985b94efe79566d2d06f6081e65fb66478ff
Summary:
Changelog: [Internal]
`getInitialNotification` only expect the user info dictionary of the dictionary, not the complete formatted notification.
Reviewed By: cipolleschi
Differential Revision: D53691569
fbshipit-source-id: 9a24629d2e50544c55ea5cd16097bd88dad950ec
Summary:
Changelog: [Internal]
In D53233914 we copied PageTarget's approach for keeping track of its sessions into InstanceTarget (for keeping track of InstanceAgents). Here we complete that pattern by asserting that the agents are destroyed before their respective targets.
NOTE: We might want to encapsulate this pattern in a helper/template class at some point. For now I'm going with the explicit approach.
Reviewed By: hoxyq
Differential Revision: D53266708
fbshipit-source-id: 4a90fde6c68e87d4667c44f81f8578a7a9072474
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. *← This diff*
* Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). *← Also in this diff*
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53233914
fbshipit-source-id: 166ae3e25059bd9c9c051a0a3312a3ba78a3935a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42923
This Diff implement the logic to:
- Read some lists of class names provided by libraries that conforms to some protocols we defined as extension points.
- Generate a provider in the React-Codegen podspec, whose code lives alongside the app code.
- Glue the app and the generated code together, allowing to link custom protocols
## Changelog
[iOS][Added] - Allow libraries to provide module which conforms to protocols meant to be extension points.
Reviewed By: RSNara
Differential Revision: D53441411
fbshipit-source-id: f53bc6ea0417e6122d8918df2614bcb9937a515a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42962
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: RSNara
Differential Revision: D53661231
fbshipit-source-id: 28c376fbd08c326f117f8d420485d63e2b4b1241
Summary:
Those files are stale from Buck OSS. I'm removing them.
I'm also updating the RN-Tester instructions to be up-to-date.
## Changelog:
[INTERNAL] - Cleanup BUCK artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/42990
Test Plan: Nothing to test
Reviewed By: NickGerleman
Differential Revision: D53705337
Pulled By: cortinico
fbshipit-source-id: 685fc346870c5f123660cb5af2e30fb64842127a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42812
There is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
More context here D16042065.
Let's say we have
```
onLegacyStyleEvent?: ?BubblingEventHandler<LegacyStyleEvent, 'alternativeLegacyName'>
```
This will produce the following entry in the view config:
```
topAlternativeLegacyName: {
phasedRegistrationNames: {
captured: 'onLegacyStyleEventCapture',
bubbled: 'onLegacyStyleEvent'
}
}
```
This means that React expects `topAlternativeLegacyName`.
But the generated EventEmitter looks like this:
```
void RNTMyNativeViewEventEmitter::onLegacyStyleEvent(OnLegacyStyleEvent $event) const {
dispatchEvent("legacyStyleEvent", [$event=std::move($event)](jsi::Runtime &runtime) {
auto $payload = jsi::Object(runtime);
$payload.setProperty(runtime, "string", $event.string);
return $payload;
});
}
```
The native component will emit `legacyStyleEvent` (`topLegacyStyleEvent` after normalization) that React will not be able to handle.
This issue only happens on iOS because Android doesn't use EventEmitter currently.
To address this issue we'll use `paperTopLevelNameDeprecated` for the generated EventEmitters if it is defined.
Changelog: [iOS][Fixed] - Fixed support for event name override in component specs.
Reviewed By: cortinico, mdvacca, cipolleschi
Differential Revision: D53310654
fbshipit-source-id: 018d5b11d8d36e2ecf900b9d8d6fe3e2ed71f80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42809
This diff adds a legacy style event to `MyNativeViewNativeComponent`.
This is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
In this example it is `onLegacyStyleEvent` and `alternativeLegacyName`.
More context here D16042065.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53310318
fbshipit-source-id: 4dec08c872acdfd09b9939f690fb7bc777149580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42665
- Replace the internals of `InspectorFlags` to use the new `ReactNativeFeatureFlags` setup.
- Remove call sites to `InspectorFlags::initFromConfig`.
After this diff, all `InspectorFlags` are configured from `ReactNativeFeatureFlags.json`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D53049790
fbshipit-source-id: 90c2b128a9c316546c3f8f8f88e2c08a9f55ae72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42642
Removes call to `InspectorFlags::initFromConfig`, since this approach is being replaced with `ReactNativeFeatureFlags`. This change is separated out as it originally made a public API deprecation.
Changelog:
[iOS][Deprecated] - **Un-deprecates** `RCTAppSetupPrepareApp` (reverts #41976)
Reviewed By: motiz88
Differential Revision: D53048207
fbshipit-source-id: 8624020f1e9e19f9f1ee75af9b177e922e36c5d9
Summary:
CI is broken. Let's not bother attempting to fixing it as it's attempting to call `envinfo` on Windows
which no one really looks into.
Also the maintainer is unresponsive: https://github.com/tabrindle/envinfo/issues/238
Changelog:
[Internal] [Changed] - Do not invoke envinfo on windows
Reviewed By: cipolleschi
Differential Revision: D53698194
fbshipit-source-id: db90ae6e773cf0a2f72ca1fc2d5faa3f56ed2edc
Summary:
Changelog: [Internal] - We still use the `dry-run` build variant in template tests on CircleCI
Previous diff migrated `set-rn-version` to `set-version` for dry-run, prealpha, and nightly build types. I didn't realize that template test flow used `dry-run` builds. I thought it was just for commitlies (which are deprecated).
To properly migrate this site, I need to fix the template test flow to accept monorepo packages at the same version as the dry-run react-native version (1000-<commithash>)
For now, let's just make this change more precise, and only update the nightly flow
See this error: {F1455663616}
Template test flow doesn't fake publish the monorepo packages at this version -- they're still using the versions off of main
Reviewed By: mdvacca
Differential Revision: D53688238
fbshipit-source-id: 6b64baca7eac842f2207fe13a3046b18459228da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42958
Changelog: [Internal] - Add support to `set-version` that we can bump the monorepo packages on main
This should be used after we cut a release branch. The release crew should then run
`yarn set-version 0.next.0-main --skip-react-native-version`
This makes sure we don't update `react-native` on main branch and keep it at 1000.0.0
This essentially replaces:
`yarn bump-all-updated-packages --release-branch-cutoff`
in this step: https://reactnative.dev/contributing/release-branch-cut-and-rc0#12-bump-minor-version-of-all-monorepo-packages-in-main
The reason for this change is to consolidate all the places where we update the version to one place, set-version.
Currently we do this in many fragmented places
* bump-all-updated-packages
* set-rn-version
* get-and-update-packages (deleted in the prev diff)
In the future, I want to get rid of `skip-react-native-version` but we'll need to remove the `1000.0.0` nomenclature. This unblocks us to just use this script for now.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53648688
fbshipit-source-id: 4f76366f8d340ec5aeaba1d3a26eba8b18a0166c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42903
Changelog: [Internal] - Update publish-npm to use `set-version` for nightly builds
Now that `set-version` basically does what `set-rn-version` does, this diff uses this logic for nightlies only (as dry-run/pre-alpha variants are non-functional right now)
This does not change the flow of build-type `'release'` -- that will still use `set-rn-version` via CircleCI ([job](https://fburl.com/code/6xo3ijwg), [script](https://fburl.com/code/bo8np0tb)) We will eventually replace that too but that will be later.
This allows us to delete `get-and-update-packages.js` which was a helper written specifically for updating monorepo packages for nightlies.
The purpose of this is to eventually conform all version updates to use `set-version` in all types of releases (nightlies, stable)
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D53487874
fbshipit-source-id: 734b528ef5bd095ac68f86701ae105daa30c7d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42964
We've seen npm publishes fail occasionally in CI as part of this script, most recently in S391653. This change adds a single retry, per package, during the execution of this script, in an attempt to reduce the chance of manual interventions after a broken pipeline.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607808
fbshipit-source-id: 526d9c33d51ec57702efba3c199bad313c1bf2d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42944
Updates `find-and-publish-all-bumped-packages` to use the npm registry as the source of truth, similar to tools like Lerna (`lerna publish from-package`). **This enables safe reruns of the publish script**, and replaces the previous Git-diff-detection implementation.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53607807
fbshipit-source-id: 135808b7ce36cf463c9f53a8059500b83f8b6679
Summary:
This adds `react-native/metro-config` to the monorepo build tool and emits the missing typescript declarations.
Right now, we do have typescript declarations on `metro-config`, but not `react-native/metro-config`. Which makes everything a bit harder extend from "[the default React Native metro config](https://github.com/facebook/react-native/pull/36502)" in Expo.
> Note, I also added the same `exports` block from `react-native/dev-middleware` for conformity.
One open question here is, why aren't we exporting _all_ helper functions from `metro-config`? To me, its a bit weird that we need both `metro-config` _and_ `react-native/metro-config` as `loadConfig` isn't exported.
## Changelog:
[INTERNAL] [FIXED] - Emit typescript declaration files for `react-native/metro-config`
Pull Request resolved: https://github.com/facebook/react-native/pull/41836
Test Plan:
Run the build tool, and check if the typescript declarations are emitted for `react-native/metro-config`.
```
yarn build metro-config
```
Reviewed By: hoxyq
Differential Revision: D51943453
Pulled By: huntie
fbshipit-source-id: cfaffe5660053fc9a9fcbe3dacf7f6ccc2bde01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42948
Changelog: [Internal]
Refactor URL construction for DevTools.
Next diffs in the stack will add additional URL query params.
Support for both absolute and relative `devServerUrl`s maintained.
Reviewed By: hoxyq
Differential Revision: D53620915
fbshipit-source-id: 4a64c49c3479ede2add9f39a24448787d8609172
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42858
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico, rshest
Differential Revision: D53393471
fbshipit-source-id: 3f896f7d7c51f276a3f743d39dc851cb47ca538a
Summary:
In setups with `pnpm` `react-native/virtualized-lists` gets bundled incorrectly because of the following error:
`Module not found: Error: Can't resolve 'react'`
As 'react' is used inside of the package, it should declared explicitly, instead of being a phantom dependency.
## Changelog:
[GENERAL] [FIXED] - Declare missing peer dependency `react`
Pull Request resolved: https://github.com/facebook/react-native/pull/42947
Test Plan: not needed
Reviewed By: NickGerleman
Differential Revision: D53617462
Pulled By: cortinico
fbshipit-source-id: 19a8fed94263646b0af93339d5c014e629dfa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42956
In the component codegen system, when the header prefix is an empty string, we generate includes using angle brackets, like this:
```
#include <EventEmitter.h>
```
This fails to compile in buck.
If we instead generate includes using quotations, buck compiles again.
```
#include "EventEmitter.h"
```
So, changes: if the headerPrefix is an empty string, generate includes using quotes.
This is a followup to D51811596.
Changelog: [Internal]
Reviewed By: fkgozali, dmytrorykun
Differential Revision: D53487111
fbshipit-source-id: e90a8b9fd4f8a2a93a0f4ad0ed989af26ad122c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42897
Changelog: [Internal] - Update nightly flow to use set-version
This change fixes `set-version` to update the `packages/react-native` native source and build files (as `set-rn-version` does) -- this was an oversight but not an issue as `set-version` isn't actually used anywhere right now.
Reviewed By: huntie
Differential Revision: D53463414
fbshipit-source-id: d0d9e4bbe246cccb8643a6ebf9794122bc343433
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42927
This bumps Kotlin to 1.9.22 which is the latest in OSS and closer to the version we use inside fbsource.
Turns out that Explicit API mode was not enabled correctly, so I had to go over all the Kotlin classes
and correctly set them to `public` if they were intended to be for public consumption.
I updated some of them to `private` or `internal` but otherwise I've defaulted to `public` which is the default
we have right now.
Changelog:
[Android] [Changed] - Kotlin to 1.9.22
Reviewed By: cipolleschi
Differential Revision: D53576844
fbshipit-source-id: dd8b08ce9bf87f738159f60fd850e3e3bc490ebc
Nick Gerleman
Moti Zilberman
Rubén Norte
Luna Wei
Nicola Corti
Riccardo Cipolleschi
Phillip Pan
Dmitry Rykun
Alex Hunt
David Vacca
Alex Hunt
Edmond Chui
m-nakamura145
Jakub Romanczyk
Ramanpreet Nara
Joe Vilches