Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.65 stable #31990

Closed
wants to merge 66 commits into from
Closed

0.65 stable #31990

wants to merge 66 commits into from

Conversation

brian-reed-software
Copy link

I would like to fix this issue --> Nested View and Text vertical alignment issue. #31955

[General] [Fixed] - Nested View and Text vertical alignment issue. #31955

Test Plan

Removed nesting View , Inside and Outside text on the same vertical line.

image
image

Huxpro and others added 30 commits April 29, 2021 20:51
[AppContainer] Add back legacy rootTag childContex
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.

Next step is to commit this to 0.64 release branch

allow-large-files

Changelog: [iOS] Fix builds on Xcode 12.5

Reviewed By: fkgozali

Differential Revision: D28071808

fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
Changelog:
[Breaking][Changed] - Bump Hermes to 0.8.0

allow-large-files

Reviewed By: nadiia

Differential Revision: D28087209

fbshipit-source-id: 2f26901d07ad29093d44e4a71eaa7b7c4ad9afb2
Summary:
Changelog:
[General] - Reflect Hermes release version from HermesBadge

It was a common footgun that an unexpected version of Hermes
engine is used in a RN app. To help with indicating this from
the runtime, Hermes exposes its OSS release version from
`HermesInternal.getRuntimeProperties()` Starting from 0.8.0.

This diff updates the `HermesBadge` used by `NewAppScreen`
header to reflect the version.

Reviewed By: nadiia

Differential Revision: D24436609

fbshipit-source-id: 8ba45be598a7d5af0e38f5044f9370fc7e1eb9a1
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.

Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293

Reviewed By: lunaleaps

Differential Revision: D25507604

fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
Implement the API for querying the properties of an object found in a
heap snapshot.

Now when you are debugging and take a heap snapshot, you can hover
over an object and inspect it!

Only works for subclasses of JSObject. Doesn't work for stuff like HiddenClass,
PropertyAccessor, native objects like WeakValueMap, etc. Those internal objects
display "Preview is not available" which matches what Chrome prints for its own
internal stuff.

Changelog: [Internal]

Reviewed By: avp

Differential Revision: D27834672

fbshipit-source-id: 607a8984b5a48b76c5ae57f9bd5bf53168f3ec3f
Summary:
This fixes multiple compile errors when building RNTester with Hermes enabled:
- `Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')`
- `'event2/event-config.h' file not found`
- tons of missing files (all added to RCT-Folly/Futures)

Changelog: [iOS] Fix Hermes build on folly version 2021.04.26.00
allow-large-files

Reviewed By: RSNara

Differential Revision: D28128087

fbshipit-source-id: ee7cb6fda72d00d22f6182d958aa8ba55939f158
…UIManager registered

Summary:
This diff refactors the UIManagerHelper.getUIManager method to return null when there's no UIManager registered for the uiManagerType received as a parameter.

This is necessary to workaround: #31245

changelog: [changed] UIManagerHelper.getUIManager now returns null when there's no UIManager registered for the uiManagerType received as a parameter

Reviewed By: fkgozali

Differential Revision: D28242592

fbshipit-source-id: c3a4979bcf6e547d0f0060737e41bbf19860a984
Summary:
This is a follow up to my diffs from a couple weeks ago bumping folly version to 2021.04.26. Unfortunately, those diffs did not work when Hermes was enabled, and Flipper was disabled, this fixes that.

I've tested the matrix of Hermes enabled/disabled and Flipper enabled/disabled.

Changelog: [iOS]  Fix Hermes + no Flipper build on Xcode 12.5

Reviewed By: yungsters

Differential Revision: D28325790

fbshipit-source-id: e58e1ba4730e7989c48dfd2aae06d91c1d3687db
Summary:
I added onPressIn & onPressOut props to Text to help implement custom highlighting logic (e.g. when clicking on a Text segment). Since TouchableOpacity can't be nested in Text having custom lineHeights without bugs in some occasions, this modification helps to replicate its behavior.

## Changelog

[General] [Added] - Add onPressIn & onPressOut props to Text

Pull Request resolved: #31288

Test Plan:
```
const [pressing, setPressing] = useState(false);

<Text
  onPressIn={() => setPressing(true)}
  onPressOut={() => setPressing(false)}
  style={{ opacity: pressing ? 0.5 : 1 }}
/>
```

Thanks in advance!

Reviewed By: yungsters

Differential Revision: D27945133

Pulled By: appden

fbshipit-source-id: 8342ca5f75986b4644a193d2f71eab3bc0ef1a5f
Summary:
While testing 0.65, we noticed issues with hermes on iOS in the template projects
These changes create a subspec to the react-core pod so that it can access hermes header correctly.

## Changelog

Not applicable

Pull Request resolved: #31559

Test Plan: I've ran e2e manual test. Tested RNTester manually also. Then tested a project inited with hermes and the default template

Reviewed By: mhorowitz

Differential Revision: D28564642

Pulled By: Huxpro

fbshipit-source-id: cfcb3363254f62a0e514ec99159b32f841ee4463
Summary:
Upgrade jsc-android to latest stable version. Hopefully this should finally fix #25494.
Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable

## Changelog

[Android] [Changed] - Upgrade jsc-android to 250230.2.1

Pull Request resolved: #31304

Test Plan: Launch app with new jsc-android and see everything works fine.

Reviewed By: TheSavior

Differential Revision: D28630503

Pulled By: yungsters

fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary:
23d9bf1 looks like it accidently removed `localeIdentifier` from I18nManager.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[General] [Fixed] - Re-added localeIdentifier to I18nManager constants

Pull Request resolved: #31589

Reviewed By: GijsWeterings

Differential Revision: D28690202

Pulled By: fkgozali

fbshipit-source-id: 543a491f89789bca5629e1251c94fd055ec4a801
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.

## Changelog

[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1

Pull Request resolved: #31593

Test Plan: rn-tester builds and runs as expected

Reviewed By: mdvacca

Differential Revision: D28711942

Pulled By: ShikaSD

fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
API of Jest transformers is changing in Jest 27. The new version of `jest/create-cache-key-function` handles both current versions of the API and the upcoming 27 API.

Ref: jestjs/jest#10834

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Internal] [Changed] - Use version of `jest/create-cache-key-function` compatible with upcoming Jest v27 release

Pull Request resolved: #30637

Test Plan: I've tested locally that it works with both a `jest@latest` and `jest@next` release.

Reviewed By: yungsters

Differential Revision: D28807361

Pulled By: hramos

fbshipit-source-id: 9d9ccb4d7f91b30bcbf3d28202bb74ce7499a91b
Summary:
JetBrains [republished](https://youtrack.jetbrains.com/issue/IDEA-261387) trovej to Maven Central, so we can now use that dependency instead

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D28355119

fbshipit-source-id: 9dd35b946bf9a09b06d831159be72fa9e5e94837
Summary:
FBJNI version have been updated recently and the new version is available on Maven Central, so we can remove this exception.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D28355443

fbshipit-source-id: 1b3d88b668fed12deb786d36672f07dc98709aa0
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.

Both Gradle and Buck successfully download all the dependencies.

## Changelog

[Android] [Changed] - Remove jcenter

Pull Request resolved: #31609

Test Plan: rn-tester builds and runs as expected.

Reviewed By: mdvacca

Differential Revision: D28802444

Pulled By: ShikaSD

fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
Homebrew on M1 installs executable binaries in **/opt/homebrew/bin** (See https://brew.sh/2021/02/05/homebrew-3.0.0/), and FBReactNativeSpec.build is failing because it couldn't find node. This PR changes find-node.sh script to add /opt/homebrew/bin into $PATH.

The way **react.gradle** trying to execute node is not using user environment variables, but system defaults, so it couldn't find it. I removed node execution, and hard coded cli path in parity with iOS https://github.com/facebook/react-native/blob/d1ab03235cb4b93304150878d2b9057ab45bba77/scripts/react-native-xcode.sh#L106

Fixes #31621 #31592

## Changelog

[General] [Changed] - find-node.sh supports Homebrew on M1

Pull Request resolved: #31622

Test Plan: On M1, create a RN project and it'll fail to build iOS app. Apply the patch, and build will succeed.

Reviewed By: ShikaSD

Differential Revision: D28808206

Pulled By: hramos

fbshipit-source-id: 8b313b6685462a15e67d99c61a0202d17fece1ec
Summary:
Bumped react-native-community/cli to v6 to update metro to 0.66 to fix fast-refresh issues
Also updated the manual test e2e script for easier testing. (using npm install would create a package-lock.json and conflict with yarn.lock)

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[GENERAL] [UPDATE] - updated react-native-community/cli to v6 (hence updating metro to 0.66)

Pull Request resolved: #31597

Test Plan: I've tested fast-refresh works with / without hermes

Reviewed By: TheSavior

Differential Revision: D28852660

Pulled By: yungsters

fbshipit-source-id: af338e4dd1d52c62949d71f42773963d89bca9db
Summary:
While it is possible in the React Native implementation for Android to provide a custom configuration for HTTP requests, the iOS implementation does not allow for the same customization. As the NSURLSession used for HTTP requests on iOS is configured internally, one may for instance not supply an ephemeral configuration for HTTP requests. Other concerns related to the given problem have been addressed in the community: react-native-community/discussions-and-proposals#166. I did make a PR with an RFC in the community repo, but after some discussion in the said repo, I figured I might as well make a PR with a suggestion :)

## Changelog

[iOS] [Added] - Allow for configuring the NSURLSessionConfiguration

Implement a C function `RCTSetCustomNSURLSessionConfigurationProvider` which gives the app programmer the ability to provide a block which provides an NSURLSessionConfiguration that will be used for all HTTP requests instead of the default configuration. The provided block will be called when the session configuration is needed.

Pull Request resolved: #27701

Test Plan: Unsure if this can be tested in any other way than uncommenting the example code in `RNTester/RNTester/AppDelegate.mm`.

Reviewed By: yungsters

Differential Revision: D28680384

Pulled By: JoshuaGross

fbshipit-source-id: ae24399955581a1cc9f4202f0f6f497bfe067a5c
Summary:
Gradle has been showing below warning for a while, and this PR fixes the warning using maven-publish plugin, thus taking us one step closer to Gradle 7.x.

> The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.9/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins

Configured maven-publish plugin according to https://developer.android.com/studio/build/maven-publish-plugin, also added **installArchives** task for backwards compatibility.

## Changelog

[Internal] [Changed] - use maven-publish plugin to build and publish Android artifact

Pull Request resolved: #31611

Test Plan: ./gradlew :ReactAndroid:installArchives will create **android** directory for local maven repository with **react-native** package.

Reviewed By: yungsters

Differential Revision: D28802435

Pulled By: ShikaSD

fbshipit-source-id: 7bc7650a700e1a61213c5ec238bcb24fdca954db
Summary:
Bump buildToolsVersion to 30.0.2, default version of Android Gradle Plugin 4.2.0. Fixes parity with #31593

## Changelog

[Android] [Changed] - Bump buildToolsVersion to 30.0.2,

Pull Request resolved: #31627

Test Plan: Newly created projects will use build tools 30.0.2 to build dependencies.

Reviewed By: yungsters

Differential Revision: D28833598

Pulled By: ShikaSD

fbshipit-source-id: 009472d27ea7103bdc7e5a6a941ab529d982f2da
Summary:
allow-large-files

This bumps the flipper dependencies to 0.91.

Fresco deps are not in mavenCentral jet, so picked those from bintray, but pinged the team and they'll follow up on it. See also: facebook/fresco#2603

This primarily bumps to the latest pods we have everywhere, which solves several build issues, like reported in #31480

After this change it should no longer be needed to pass custom version overrides to `use_flipper`, as the defaults will be up to date.

In the template project, I changed the version rangers to exact numbers, so that results of `react-native init` are more consistent / predictable over time, as suggested in the discord channel by Brent

In the long term we are investigating whether we can remove most of the transitive deps by not using RSocket, which is a bigger project plan that should help reduce build issues and times, especially on iOS.

cc priteshrnandgaonkar  passy kelset

## Changelog

[general][changed] - [iOS] Update Flipper to 0.91.1, fixed iOS build support for i386, `use_flipper!()` will no longer need custom overrides to build with XCode 12.5

Pull Request resolved: #31562

Test Plan:
_N.B. Locally tested in XCode 12.4 only, but bumped versions have been confirmed to work on 12.5 before by others_

* React Native CI
* Flipper CI with same versions of deps: https://github.com/facebook/flipper/actions/runs/863607686
* Was able to connect from both Android and iOS to Flipper. Couldn't really test further due to a bundling error I didn't understand, suggestions welcome

![Screenshot 2021-05-21 at 11 32 52](https://user-images.githubusercontent.com/1820292/119133806-3d090880-ba34-11eb-8c0b-1ede7bc13751.png)
![Screenshot 2021-05-21 at 12 59 13](https://user-images.githubusercontent.com/1820292/119133892-5c079a80-ba34-11eb-9e72-278c427fdeb0.png)

Reviewed By: fkgozali

Differential Revision: D28623601

Pulled By: mweststrate

fbshipit-source-id: 22130d07821569851956453c4ee6a594b6b83928
kelset and others added 12 commits June 17, 2021 12:11
Summary:
The native libraries are compiled outside of the usual Android build flow using separate CLI task. Because of that, shared native libraries may not exist when AAR is bundled, resulting in weird sequencing issues.

This change updates gradle dependency graph, executing RN native build before Android part (as it is done in RNTester already).

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D29209249

fbshipit-source-id: 36386c78996b1cd9b1731735e36e571199e9e81b
…lPointerException: bio == null crash (#31822)

Summary:
Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack:

```
java.lang.NullPointerException: bio == null
       at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java)
       at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660)
       at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566)
       at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584)
       at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480)
       at okhttp3.internal.Util.closeQuietly(Util.kt:501)
       at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245)
       at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106)
       at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74)
       at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255)
       at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32)
       ...
  ```

![Screen Shot 2021-07-07 at 1 38 23 PM](https://user-images.githubusercontent.com/8868908/124711795-b5fee980-df28-11eb-98c4-9668661340b6.png)

This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized.

 **The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1.

 Related discussion:
 [https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597)
 [https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/)

cc dulmandakh fkgozali

## Changelog
[Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1.

Pull Request resolved: #31822

Test Plan: Manual & Automated from CI

Reviewed By: fkgozali

Differential Revision: D29590198

Pulled By: ShikaSD

fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d
Summary:
Fixes #31774.

This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.

This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.

The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.

https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95

This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Fixed] - Fix support for blobs larger than 64 KB

Pull Request resolved: #31789

Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.

<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />

Reviewed By: ShikaSD

Differential Revision: D29674273

Pulled By: yungsters

fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
# See PR
#29728

# From PR Author
Using `PlatformColor` with border colors doesn't work currently when switching dark mode as the information is lost when converting to `CGColor`. This change keeps the border colors around as `UIColor` so switching to dark mode works.

```ts
<View
  style={{
    borderColor: DynamicColorIOS({ dark: "yellow", light: "red" }),
    borderWidth: 1,
  }}
>
...
</View>
```
This view will start with a red border (assuming light mode when started), but will not change to a yellow border when switching to dark mode. With this PR, the border color will be correctly set to yellow.

## Changelog

[iOS] [Fixed] - Allow PlatformColor to work with border colors

Pull Request resolved: #29728

Test Plan:
1. Assign a `PlatformColor` or `DynamicColorIOS` to a view border color.
2. Toggle between dark / light mode. See the colors change.

Reviewed By: lunaleaps

Differential Revision: D29268376

Pulled By: p-sun

fbshipit-source-id: 586545b05be0beb0e6e5ace6e3f74b304620ad94
* Bump Flipper to 0.93 (#31708)

Summary:
Pull Request resolved: #31708

Changelog:
[general][changed] - [iOS] Update Flipper to 0.93.0

Reviewed By: PeteTheHeat

Differential Revision: D29060305

fbshipit-source-id: 2ff109930437bfc90e8ce441fa681de867206397

* Update Podfile.lock

* bump(hermes): bumped hermes to 0.8.1

While current dependencies included the new version in the range, bumping it make sure that no one use the old one because of a lock file

Co-authored-by: Michel Weststrate <[email protected]>
…ive (fix for 0.65-stable)

Closes T97407621.

This change is not present in main, and needs to be upstreamed. See T97370374.
@facebook-github-bot
Copy link
Contributor

Hi @brian-reed-software!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

@chrisbobbe
Copy link

Did you mean to make a PR from the 0.65-stable branch into the main branch? Or do you have commits you made yourself that you'd like to be reviewed?

@brian-reed-software
Copy link
Author

brian-reed-software commented Aug 9, 2021 via email

mysport12 and others added 8 commits August 11, 2021 12:57
Summary:
- Fixed iOS codegen script incorrectly splitting root project paths that contain spaces
react-native-community/releases#214 (comment)

iOS builds were failing on 0.64.0-rc.4 for projects that contained spaces in the root directory path. The error logs pointed to the codegen script not being able to find a directory. The path was being split at a space in one of the folder names. This PR modifies the codegen script to include the spaces and use the entire project root path.

## Changelog

[Internal] fix: codegen script failing for iOS builds on projects with spaces in root directory path

Pull Request resolved: #31141

Test Plan:
Failing Test: Upgrade or init a new project and make sure that the project root directory contains a space (ex: /Users/test/cool projects/app/). With a clean install of node_modules and pods, attempt to build the project with Xcode. The build fails with an error running the script in FBReactNativeSpec (no such file or directory).

Passing Test: Include the changes presented in this PR and rerun the failing test (clean node_modules + PR patch/clean pods). The app should build.

Reviewed By: mdvacca

Differential Revision: D28255539

Pulled By: hramos

fbshipit-source-id: d44011985750639bd2fabfd40ed645d4eb661bd7
Summary:
This changeset is limited to whitespace and reordering changes that have no effect on the output or execution of the script. The sole purpose of this changeset is to apply these trivial changes prior to making some larger adjustments to the script in a followup.

With these changes, the ordering of statements more closely matches the order they are executed in (e.g. prepare_command before the script_phase).

Changelog:
[Internal]

Reviewed By: RSNara

Differential Revision: D29527804

fbshipit-source-id: d161ed31321d68baf420457c7aa0aa23a6fc98d2
Summary:
Extend the codegen script to allow arbitrary library name to be passed along as an argument, as well as the desired output directory for TurboModules and Fabric output.

New arguments:

- `:library_name`
- `:modules_output_dir`
- `:components_output_dir`

These arguments remain optional, and in their absence, the codegen will generate output that should work for the FBReactNativeSpec core native modules use case.

Internally, the script has been updated to use the correct path for the core modules use case as well as third party modules.

Changelog:
[Internal] - Extend the codegen script to take additional parameters

Reviewed By: RSNara

Differential Revision: D29243707

fbshipit-source-id: 1921bd3e5fd62d7cbf4c8b5089acfdd112f4b014
Summary:
For any Pod that uses the codegen, create references to code-gen'd files in local filesystem regardless of Pod install status by invoking the same command used by `prepare_command` whenever `pod install` is run.

This works around the issue where CocoaPods may decide to skip running `prepare_command`. While this is expected CocoaPods behavior, external factors may result in the deletion of the original code-gen'd files in which case we need to make sure that running `pod install` will bring these files back.

See Test Plan for more details on how to reproduce the issue being fixed.

Fixes T97404254.

Changelog:

[Internal] Codegen invoked with every `pod install` regardless of pod install status

Differential Revision: D30116640

fbshipit-source-id: 81db5dff1d4c4f8ae22b5dbe822609c770789ac8
Summary:
Upgrade CLI to the v6 stable. [Changelog](https://github.com/react-native-community/cli/releases/tag/v6.0.0)

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[General] [Fix] - Bump CLI to ^6.0.0

Pull Request resolved: #31971

Test Plan: cc kelset grabbou

Reviewed By: TheSavior

Differential Revision: D30158170

Pulled By: ShikaSD

fbshipit-source-id: 392e22cb112a830778149b4a2b4a19198facf42b

# Conflicts:
#	yarn.lock
…eact-native (fix for 0.65-stable)"

This reverts commit 98e1734.
@analysis-bot
Copy link

analysis-bot commented Aug 11, 2021

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 8,919,568 -321,881
android hermes armeabi-v7a 8,406,494 -346,864
android hermes x86 9,368,535 -315,439
android hermes x86_64 9,313,999 -338,839
android jsc arm64-v8a 10,594,887 -282,547
android jsc armeabi-v7a 9,470,992 -309,610
android jsc x86 10,630,854 -284,490
android jsc x86_64 11,220,048 -305,680

Base commit: 899fa25

@TheSavior
Copy link
Member

It looks like this PR is open from the 0.65 branch, causing the diff to include significant unrelated changes. I recommend opening a new PR from the main branch with just the changes you intended.

@TheSavior TheSavior closed this Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet