Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41420
X-link: https://github.com/facebook/yoga/pull/1465https://yogalayout.com now redirects to https://yogalayout.dev
This replaces references to "yogalayout.com" with "yogalayout.dev", the same website, with a new domain. This includes:
1. Code comments
2. Yoga website config (publish action CNAME, Docusaurus config)
3. Documentation URLs in Yoga packages
Changelog:
[General][Fixed] - "yogalayout.com" to "yogalayout.dev"
Reviewed By: christophpurrer
Differential Revision: D51229587
fbshipit-source-id: b1c336a52aab5e02565071b61430d5435381dc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41412
The PR https://github.com/facebook/react-native/pull/39682
moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API.
Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method:
https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava
In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility.
Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is:
- Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method
- Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method
- com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API
changelog: [Android][Changed] Fix backward compatibility breakage
Reviewed By: fkgozali
Differential Revision: D51168413
fbshipit-source-id: 921475f4beee7c6f04912558204a1911cd74b5ca
Summary:
X-link: https://github.com/facebook/yoga/pull/1451
Pull Request resolved: https://github.com/facebook/react-native/pull/41327
The special meaning of `0.0` is now explained in the function header, and we aren't doing any sort of insensitive compare here, so the code after should be equivalent and a bit simpler.
Reviewed By: yungsters
Differential Revision: D51014264
fbshipit-source-id: 60f4a2df039f74089d5c7fabd4b7d8ac6234ba72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41317
X-link: https://github.com/facebook/yoga/pull/1449
This aims to clean up the public Yoga C API, by:
1. Documenting public YGNode, YGValue, YGConfig APIs
2. Splitting APIs for specific objects into different header files (because Yoga.h was big enough without documentation)
3. Reordering headers and definitions for consistent grouping
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50963424
fbshipit-source-id: 45124b7370256fc63aefd6d5b7641466e9a79d3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41402
Changelog: [Internal]
UIActionSheet was deprecated in iOS 8.3.
The RCTActionSheetManager class listed the UIActionSheetDelegate as an adopted protocol but none of the protocol methods were implemented.
Reviewed By: sammy-SC
Differential Revision: D50732844
fbshipit-source-id: e954f1e9a03e80561b3b066557e56c7f3d3589d4
Summary:
React Native, the text inline is made versatile by design. Being managed in an alien layout logic (i.e., text paragraph), inline views work seamlessly as if in normal **flex** layout. The capacities such as animation and relayout, however, requires extra efforts on native layer.
This PR fixed one critical issue for inline, i.e., `setState()` is not working when inline contains nested views.
Closes https://github.com/facebook/react-native/issues/41348
Demo (Fixed)
https://github.com/facebook/react-native/assets/149237137/2b42d657-4024-476b-bf0c-be25ef4f8c0c
## Problem in technical:
This issue is caused by a bug in `RCTShadowView::sizeThatFitsMinimumSize()` which accidentally unlink children (of yoga nodes) with their parent (owner). More specifically, on the critical path, it
1. first **shallow** clones the current node
```
YGNodeRef clonedYogaNode = YGNodeClone(self.yogaNode);
```
2. then calls `YGNodeCalculateLayout()` using the cloned node
3. deallocate the cloned node `YGNodeFree()`
One unseen implication of `YGNodeFree()` is to unlink all its children (because of the **shallow** clone)
```
for (size_t i = 0; i < childCount; i++) {
auto child = node->getChild(i);
child->setOwner(nullptr);
}
```
Next, let's examine,
**How nullptr of owner can cause the broken `setState()` of nested inline views**
The orphan children has two consequences:
**a**. the changes on child node (`setState()`) cannot be propagated to the parent (`YGNodeMarkDirty` -> `node->markDirtyAndPropagate();`);
**b**. `YGNodeCalculateLayout()` (`yoga::calculateLayoutImpl`) will create new children instances when orphan is detected (see below)
```
node->cloneChildrenIfNeeded(); // line 1599 # CalculateLayout.cpp
```
Both compounded are contributing the failed `setState()`. Respectively,
**a** causes early return of `YGNodeCalculateLayout()` because parent is recognized as not *dirty*;
**b** clones a new *dirty* node which replaces the child which is supposed to be *cleaned* within `YGNodeCalculateLayout()`. And this is the *dirty* node detected by the assertion mentioned in the issue description https://github.com/facebook/react-native/issues/41348.
## The fix:
The fix introduced in this PR is to relink the children with their parent in `RCTShadowView::sizeThatFitsMinimumSize()`
## Changelog:
[IOS] [FIXED] - `setState` is not working for nested inline views in text
Pull Request resolved: https://github.com/facebook/react-native/pull/41352
Test Plan:
Test directly in rn-tester
TBD
Reviewed By: yungsters
Differential Revision: D51071338
Pulled By: NickGerleman
fbshipit-source-id: 1f3d8a3e1e03cb11577f903e43f2c2cce9e07b6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41408
When FabricRenderer is used during jests it will currently error out since `nativeFabricUIManager` is nog a configured global.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51198314
fbshipit-source-id: 4db1450f6b36699311692c2cd467184f6abea518
Summary:
The goal for this PR is to further remove references for `[UIScreen mainScreen]` and migrate them to use trait collections. This helps out of tree platforms like visionOS (where the `UIScreen` is not available).
bypass-github-export-checks
## Changelog:
[INTERNAL] [CHANGED] - use currentTraitCollection for FBSnapshotTestController.m
[IOS] [CHANGED] - use key window width to assign the correct width for RCTDevLoadingView
Pull Request resolved: https://github.com/facebook/react-native/pull/41388
Test Plan:
– Check if tests passes
- Check if `RCTDevLoadingView` shows up correctly.
Screenshot:
Reviewed By: javache
Differential Revision: D51156230
Pulled By: cipolleschi
fbshipit-source-id: bbe711e0281046a082fd1680b55e2d117915ad00
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/41374
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Changelog:
[Internal] internal
Reviewed By: philIip, luluwu2032
Differential Revision: D50926872
fbshipit-source-id: be2bcea7b2ce7cb1b3f903dc92fcd2c91be267da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41313
Refactor ReactNativeHost, ReactInstanceManager & Builder of `react-native-github` to use the new way of fabric initialization using the newly added class `FabricUIManagerProviderImpl.java` instead of JSIModule and thereby also refactoring the call site in FbReactInstanceHolder.java
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50783751
fbshipit-source-id: 0a9d3412bc995834cafa8fbaec2ff17e321d9906
Summary:
In pnpm setups, codegen will fail during build because it cannot find its dependencies. Some of the dependencies it relies on at runtime are currently declared under `devDependencies`. This change moves them to `dependencies`.
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/codegen` not being able to resolve dependencies in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/41398
Test Plan: We are currently trying to [enable pnpm mode](https://github.com/microsoft/rnx-kit/pull/2811) in rnx-kit and hit this issue. We've patched this package locally and it works.
Reviewed By: christophpurrer
Differential Revision: D51169116
Pulled By: NickGerleman
fbshipit-source-id: 28906a0de412c660d2fc42f62deaf77240d27a58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41385
Changelog: Internal
Adding a Cxx TM example which adds a listener and returns a subscription to remove that listener from the TM.
You should be able to use this with React Hooks - https://legacy.reactjs.org/docs/hooks-reference.html
E.g.
```
useEffect(() => {
const subscription = NativeCxxModuleExample.setValueCallbackWithSubscription(
callbackValue => // use it
);
return subscription;
});
```
Reviewed By: shwanton
Differential Revision: D50473063
fbshipit-source-id: 4e9b92aeccff1771eb4ffad6bdaa20ba7f18435f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41360
Changelog: [Internal]
This is Flipper-only, React DevTools inject these internals in `connectToDevTools` call
Mostly for 2 reasons:
- For React DevTools' hook being accessed only in one place (AppContainer-dev)
- This logic is not related to Inspector itself
Reviewed By: GijsWeterings
Differential Revision: D50559547
fbshipit-source-id: 2127f3a20b71261858fdfc004a372d1d95ced164
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41291
Changelog: [Internal]
We have the same logic in 3 different places, encapsulating access to React DevTools hook in one place, all other components that require agent will get it as a prop.
Reviewed By: GijsWeterings
Differential Revision: D50559550
fbshipit-source-id: f3667a82ca48a36032c60c730df8f661098401ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41307
Changelog: [Internal]
To be able to use it in other possible places.
Reviewed By: javache
Differential Revision: D50952773
fbshipit-source-id: f21f4553e7f51ab0683a6adb834dc5c90c33c927
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41285
Changelog: [Internal]
I have an ongoing work on improving debugging overlays, lots of changes in these files are planned.
- Split `AppContainer` into 2 implementations: DEV and PROD
- Rewrite to functional components
Reviewed By: javache
Differential Revision: D50559549
fbshipit-source-id: 3790f149d504bd45be78c6f3103e05677f3a107d
Summary:
https://github.com/facebook/react-native/issues/41308 introduce the possibility to run e2e tests if a commit contains #run-e2e-tests in the commit message.
This PR builds on top of that, and let users to run e2e tests by adding a comment with with #run-e2e-tests
## Changelog:
[Internal] - Allow to run e2e tests from comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41311
Test Plan: Not sure it can be tested until the PR is merged... ¯\_(ツ)_/¯
Reviewed By: dmytrorykun
Differential Revision: D51111543
Pulled By: cipolleschi
fbshipit-source-id: e6c55950552f03830fa35c89d385ab9b17f8facb
Summary:
This PR aims to make scripts building hermes locally more extensible for out-of-tree platforms. It will make it easier for forks like visionOS to add additional `elif` statements.
As a side benefit this PR fixes Hermes builds for MacOS 😄 (I've checked that it now builds correctly)
## Changelog:
[IOS] [ADDED] - make build-hermes-xcode.sh more extensible for out-of-tree platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/41387
Test Plan: Run the local Hermes build by running `USE_HERMES=1 bundle exec pod install` and check if it runs smoothly. Also, a CI check should be sufficient.
Reviewed By: dmytrorykun
Differential Revision: D51156307
Pulled By: cipolleschi
fbshipit-source-id: 1c65b84b16fc8bd0552037c6ef558543cbe03889
Summary:
Enable Flow `casting_syntax=both` in fbsource, before the announcement so that when people see it they can check it out without rebasing.
bypass-github-export-checks
bypass-lint
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D51097870
fbshipit-source-id: dfcb04000df26140c971422389b6fce0b1ba51e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41381
Noticed that when scrolling VirtualizedList's CellRenderer was re-rendering due to `onCellFocusCapture` not having a stable identify. Change the interface to CellRenderer to pass in the `cellKey` in the callback to save on creating new callbacks.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51112928
fbshipit-source-id: 3fcb974d9b5585403895746fbc45f2cf5a9fa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41342
While rewriting `Debugger.getScriptSource` messages to fetch code and source map over HTTP, we weren't checking the status code of the fetch calls. This diff fixes that and adds corresponding tests (as well as for the filesystem error case).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51013054
fbshipit-source-id: 58e7bb9fcd6a3cf92329b43fb8a139093c80d305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41341
* Extends `dev-middleware`'s test utilities to enable testing against an HTTPS server with a self-signed cert.
* Runs the CDP transport integration tests (D51002261) using both HTTP and HTTPS.
* Adds a test to explicitly cover the `ws=...` / `wss=...` variation in `devtoolsFrontendUrl` first introduced in D49158227.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51006835
fbshipit-source-id: df3db8cd865898248cd0d8f307f75949a7f313fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41335
`inspector-proxy` has special behaviour to allow a debugger connection to persist across app reloads.
In the React Native runtime, a reload is modelled as the creation of an entirely new "page" with its own ID. To insulate the debugger from this detail, the proxy advertises a separate, synthetic page on each device, with ID `-1`, that always maps to the latest React Native page reported by that device.
Here we test the message forwarding part of this functionality. The proxy also injects CDP messages (in both directions) as part of simulating a reload, but that will be tested in a separate diff.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002262
fbshipit-source-id: 296135177321a511ebbe7d9696e4e7a61275aa32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41343
Changelog: [Internal]
Adds basic tests for two-way communication between a debugger (frontend) and a target (backend) using CDP over `inspector-proxy`.
Reviewed By: blakef
Differential Revision: D51002261
fbshipit-source-id: 44e571f89437c26e76ef6e6192b2bf6244665cf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41331
`inspector-proxy`'s `Device` class currently leaks a `setInterval` handle. This is mostly harmless in current usage. In the test suite added up the stack, it shows up as a leak that prevents Jest from exiting cleanly, so let's clean it up properly.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002263
fbshipit-source-id: ca36797ce1196aa049ceb3a8e96ee53d34893fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41314
Changelog: [Internal]
Adds the beginning of a test suite for `inspector-proxy`. For maintainability, we only test functionality exposed from the `dev-middleware` boundary rather than instantiating `InspectorProxy` directly.
In this diff, the test coverage is far from complete, but this is a first stab at covering some basics. `InspectorProxyHttpApi-test` exercises the HTTP GET endpoints (`/json/list` and `/json/version`) as well as some device registration logic through the `/inspector/device` WebSocket. Some reusable helpers for server setup and device mocking are included in separate files.
As an overall strategy, I'm planning to add multiple test files that share helpers between them, not build out one massive test file with all the helpers inline. There will likely be some verbose tests when we start covering debugger-to-device communication, and I want to keep them as readable as possible.
Reviewed By: blakef
Differential Revision: D50980467
fbshipit-source-id: 962dae5a380451d6dac57eac23c4436550a39cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41359
This change migrates the remaining podspecs to the new functions, so we do not depend on hardcoded values anymore and we can scale the solution to other platforms.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068403
fbshipit-source-id: 4c0455543363ccf4272d5e8590a7c663d9c33e8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41358
This change expose a missing function to create Header Search Paths when a podspec can't depend on another one explicitly.
This also migrate the ruby code to this new function.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068390
fbshipit-source-id: ba9e09cd2f0671a9f3f00cc72496a0d5682eeb90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41357
This change migrate React-RCTBlob to the new add_dependency to improve its compatibility with macOS and to remove some maintenance burden.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030365
fbshipit-source-id: c4b9037d6d0223052d659c04a1f494508944ed2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41356
React-Core does not depends on any bit of ReactCommon, React-RCTFabric or React-NativeModuleApple, so I'm cleaning that up.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030115
fbshipit-source-id: f87dbfe99e90d52cf8c07057be22cd024e38db42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41355
This change expose a new API to react_native_pod to add dependencies that automatically configure their search paths when using frameworksa and with multiple Apple platforms.
It also migrates React-RCTAppDelegate to this new mechanism to test that it works.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51029484
fbshipit-source-id: 77dfe85419d495f7327a2f484d33f9ed8701e00d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41354
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that automate adding a dependency to a podspec and it generates the required search paths.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51027343
fbshipit-source-id: 33ac4c07112eacb08067220397e38db0a19240fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41353
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that should factor out the platforms from the generation of header search paths.
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51026356
fbshipit-source-id: 7cf03601d94d7680f3fdfcaf52b2fd6bcd48c5b4
Summary:
This change allow our CI to run E2E tests using a specific tag in the commit message
## Changelog:
[Internal] - Allow to run e2e test using a specific tag in the last commit message
Pull Request resolved: https://github.com/facebook/react-native/pull/41308
Test Plan:
CircleCI is green
Tested interacting with the PR/branch
Reviewed By: NickGerleman
Differential Revision: D50975588
Pulled By: cipolleschi
fbshipit-source-id: 6318800d7e86e1cab394af2b320e280304189dd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39036
Changelog: [General][Changed] Use `hermes-parser` instead of `flow-parser` to parse Flow Codegen specs.
`hermes-parser` is a WASM build of the Hermes parser (plus supporting code), maintained by the Flow and Hermes teams. It is the recommended way of parsing Flow code in Node and its benefits (compared to `flow-parser`) include better performance and improved type safety.
Here we update `react-native/codegen` to use `hermes-parser` instead of `flow-parser`. Both parsers produce ASTs that conform to the ESTree spec so this is mostly a drop-in replacement.
In future work we should be able to use the improved AST types available in `hermes-estree` to improve type safety within `react-native/codegen` itself.
Reviewed By: huntie
Differential Revision: D48384078
fbshipit-source-id: 310ad150ec62671ba395b0e2f6415ccae97ac04d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39035
Changelog: [General][Fixed] Flow syntax errors in Codegen specs are no longer ignored.
Instead of throwing errors like most parsers, the `flow-parser` package returns errors as part of the AST (along with a best-effort parse). It turns out that `react-native/codegen` ignores such errors and only detects a subset of them after the fact. Here we change the behaviour to immediately throwing a descriptive error message (containing the file name and a code frame).
**This change is theoretically breaking** for any published packages that already contain broken Flow code (that somehow doesn't happen to affect the Codegen output today). Hopefully, anyone using Flow-flavoured RN Codegen is also typechecking with Flow and/or building with Metro (which would both flag the same errors), so the impact should be fairly contained.
Reviewed By: huntie
Differential Revision: D48385786
fbshipit-source-id: c7e1f5fb64a61fb0eb9e9f8f7501b43264c9626c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41346
X-link: https://github.com/facebook/yoga/pull/1452
This removes the last remnant from `Yoga-interna.h`, `YGNodeDellocate()`. The API is renamed to `YGNodeFinalize` to give it the explicit purpose of freeing the node from a garbage collector, and made public with that documented contract.
With that, every top-level header is now a public API, and Yoga's JNI bindings do not need to rely on private headers anymore.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51014340
fbshipit-source-id: 553f04b62c78b76f9102cd6197146650955aeec5
Sunbreak
Nick Gerleman
David Vacca
Arushi Kesarwani
Phillip Pan
ehsemloh
Pieter De Baets
Oskar Kwaśniewski
Gabriel Donadel
Arushi Kesarwani
Christoph Purrer
Sam Zhou
Tommy Nguyen
Ruslan Lesiutin
Riccardo Cipolleschi
George Zahariev
Intl Scheduler
hieu9102002
Moti Zilberman
Riccardo Cipolleschi