Summary:
The new Hermes scripts need to be included in the `react-native` npm.
The `shelljs` dependency that was used by the Hermes scripts is a dev dependency, so instead of adding to the `react-native` npm size, we refactored its use out of hermes-utils.js.
Changelog:
[General][Added] - Add Hermes scripts to package
Reviewed By: cortinico
Differential Revision: D36387135
fbshipit-source-id: 12d0bc29d365c4cb18d33a0d390e6e7d34864b7a
Summary:
This PR tries to simplify the `use_flipper` logic:
- makes `use_flipper` a configuration inside `use_react_native`'s options
- uses the already present `production` flag in the `use_react_native`'s options to decide if add or not the Flipper pods
- Simplifies the logic to download the flipper dependencies
This PR also adds a workaround for https://github.com/facebook/react-native/issues/33764
## 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
-->
[iOS] [Changed] - Move `use_flipper` logic inside `use_react_native` and simplify the Flipper dependencies logic
Pull Request resolved: https://github.com/facebook/react-native/pull/33882
Test Plan: Executed a pod install with and without flipper and with isProduction true
Reviewed By: cipolleschi
Differential Revision: D36592338
Pulled By: f-meloni
fbshipit-source-id: 3c3f773151513e27e251f18865986e942a96ffd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33893
The previous diff was breaking the external CI tests on Windows because of the file separators.
The fix was to use UNIX separator but to apply `path.normalize` to make sure that the path is platform agnostic.
## Changelog
[General][Fixed] - Make tests pass for windows
Reviewed By: cortinico
Differential Revision: D36597593
fbshipit-source-id: 47731f34a08c778268a6cc9674257403985d4599
Summary:
For published RN releases, use a published hermes-engine pod that corresponds to the current React Native version.
For unpublished RN versions, continue consuming the local hermes-engine pod which requires building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36533683
fbshipit-source-id: 963a0f0e24baaf73a87c9bae4bc20d83757bbfde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33891
This diff adds a function to clean up folders and empty files (if any) after the codegen runs in the OSS.
To align how iOS and Android behave in the codegen, we now have to preemptively create folders that we may not need later.
Thanks to this function, we recursively the folders in the codegen and we delete them if they are empty.
## Changelog
[iOS][Added] - Add function to cleanup codegen folders
Reviewed By: cortinico
Differential Revision: D36594999
fbshipit-source-id: 904aa2442c0d9621b7ec77c31f7be9daa4e7b7e1
Summary:
Currently this [section](https://reactnative.dev/docs/next/new-architecture-app-intro#ios-enable-c17-language-feature-support) of the Playbook tells us to set CLANG_CXX_LANGUAGE_STANDARD = "c++17" in the main app target for the new architecture to work.
Would be nice to be able to automate that instead
## 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
-->
[iOS] [Added] - Cocoapods function to add the `CLANG_CXX_LANGUAGE_STANDARD` to all the targets if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/33863
Test Plan:
I've created some unit tests for the newly added function.
I've executed pod install and the ruby tests locally.
Reviewed By: cipolleschi
Differential Revision: D36484366
Pulled By: f-meloni
fbshipit-source-id: 553b092e747bef11d82195619ae1058985fdc325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33864
This Diff aligns the way in which iOS and Android codegen the modules and components.
Android takes all the JS in the project root folder and creates components starting from there.
iOS used to required to specify a specific path for each component, within a JSON field called `libraries`. This Diff let iOS work in the same way as android does
**Backward compatibility:** This diff still support the old way for iOS, but we are deprecating it.
## Changelog
[iOS][Added] - Support codegen from a single folder
Reviewed By: cortinico
Differential Revision: D36473005
fbshipit-source-id: 1e8cf0f9764f529c02e948984c74d1982a84030b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33870
I'm fixing a broken CI on master for `test_windows` as `metro-memory-fs` doesn't
automatically recognize the platform but needs to have it passed in input.
It was currently failing to parse a `C:\...` path. This fixes it.
Changelog:
[Internal] [Changed] - Fix `test_windows` by passing the correct platform to the Metro Virtual FS
Reviewed By: cipolleschi
Differential Revision: D36507564
fbshipit-source-id: 39dfd7e9ce492d126fbb513a70ec5a60965c61fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33869
When I disabled the Javadoc pubblication as it was failing on CI,
I forgot to turn off the verification that the -javadoc artifact is included
inside the NPM package. This caused `build_npm_package-1` to fail on main.
I'm fixing it here.
Changelog:
[Internal] [Fixed] - Do not fail if -javadoc.jar are missing in the final NPM package
Reviewed By: cipolleschi
Differential Revision: D36507320
fbshipit-source-id: 3836de5212de91bb44e0e586564b46114ca346b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33818
This Diff moves the fabric setup from the `react_native_pods` script to its own `fabric` file.
It also introduces tests for the file and some test utilities.
## Changelog
[iOS][Changed] - Move fabric setup to its own file
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36344911
fbshipit-source-id: 586186684be2c0080f247390f26145f2defa9e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33852
Similarly to buildAll and cleanAll, I'm creating a downloadlAll task
which is aligning the behavior of the download task we're doing on CIs.
I've also updated the Offline Cache as we're now storing a bigger set of dependencies.
Changelog:
[Internal] [Changed] - Setup a toplevel downloadAll task
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D36441728
fbshipit-source-id: f847b5e665c64e0b4b93d984bbc1b64c00a3b4f7
Summary:
Use pre-built hermesc if available by generating a ImportHermesc.cmake file that points to the hermesc binary. Recent `react-native` releases should have hermesc available in sdks/hermesc.
Hermes build scripts have been updated to support a `HERMES_OVERRIDE_HERMESC_PATH` envvar which can point to this generated ImportHermesc.cmake file.
Pull Request resolved: https://github.com/facebook/react-native/pull/33827
Changelog:
[iOS] [Changed] - Use pre-built HermesC if available in current React Native release
Reviewed By: cortinico
Differential Revision: D36024615
fbshipit-source-id: 476569f73309f9bd142f28cb02d1f7d57b6cbc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33825
Updates the CocoaPods build scripts to consume the prepare-hermes-for-build script, replacing the now redundant set of Ruby code that would previously set the filesystem up.
Changelog:
[iOS] [Changed] - When building Hermes from source, the filesystem will now be prepared using the new hermes-utils.js scripts, outside of CocoaPods
Reviewed By: cortinico
Differential Revision: D36336633
fbshipit-source-id: a4506db80c039529b14b0290d2f0b54fae78dcf2
Summary:
Adds a script that uses the new hermes-utils.js functions to prepare the local filesystem for Hermes to be built from source (e.g. download the Hermes source code tarball and extract it into its final location).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36334624
fbshipit-source-id: 012f758ecda07931bdb0ab1728b87733bf5af16a
Summary:
Currently, the tasks for downloading, expanding, and preparing Hermes to be built for Apple targets are split across the Circle CI and CocoaPods configs.
This diff sets out to consolidate these tasks into a single hermes-utils.js script that can be reused across CI and build systems.
The release script that is used to assign the Hermes tag for a given React Native version has been moved into `scripts/hermes`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36329356
fbshipit-source-id: 0222070adf201fa533b607a183471396d45c6caf
Summary:
Patch release bumps that just change arm64 slice packaging
See https://github.com/facebook/flipper/issues/3117#issuecomment-1123759397
These pods were just released by lblasa and this PR integrates them - I personally confirm success on an arm64 doing a macCatalyst build for the first time since react-native 0.64, and users report intel works fine as well - no regression
## Changelog
[Catalyst][Fix] - use pods with arm64 macCatalyst slices
Pull Request resolved: https://github.com/facebook/react-native/pull/33809
Test Plan:
Run a macCatalyst build on intel machine and m1 machine, I use this harness as part of release-testers facebook group, and it exercises macCatalyst build if you pass in a valid development team (for signing) https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh
(the test harness is locally modified to no longer exclude M1 builds and with a patch-package that implements this PR, pending this merge+release...)
Reviewed By: cortinico
Differential Revision: D36339335
Pulled By: cipolleschi
fbshipit-source-id: d4574fc960e6ff345b31a83ff4629e22edfcf2f7
Summary:
Copy Hermes build scripts to React Native repository for greater control over the build pipeline when used in RN.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D36295406
fbshipit-source-id: 54bf4173b6c75db35de828378e6f5782a248ed2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33802
We use to have a couple of tests for the script phases script that were not running during the CI.
This diff connect them with the two CI, so that they run together with the other ruby tests.
## Changelog
[iOS][Added] - Run script phases tests in CI
Reviewed By: fkgozali
Differential Revision: D36283211
fbshipit-source-id: 01b257cdc99b0bc196d60d49ac76cf044d61a7e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33791
This flag is used as a duplication for the `RCT_NEW_ARCH_ENABLED` flag. There is a [spot](d96806bbc6/scripts/react_native_pods.rb (L31)) in the code where, if `RCT_NEW_ARCH_ENABLED`, then the `USE_CODEGEN_DISCOVERY` is set to true as well.
Maintain two different flags for similar reasons is cumbersome and error-prone. This diff removes the `USE_CODEGEN_DISCOVERY` in favor of the `RCT_NEW_ARCH_ENABLED` flag.
## CHANGELOG
[iOS][Removed] - Remove USE_CODEGEN_DISCOVERY flag
Reviewed By: cortinico
Differential Revision: D36244618
fbshipit-source-id: 8e8979268b7aa25b895236b0c3a86fb57c6f2ea6
Summary:
This Diff moves all the Flipper.rb related setup in the cocoapods scripts to a dedicated script.
It also removes the not needed dummy files and add tests for flipper.
## Changelog
[iOS][Internal] - Extract Flipper setup in a separate file and add tests
Reviewed By: cortinico
Differential Revision: D36129808
fbshipit-source-id: 5446203a69b527146c893aa9611e98688e20b778
Summary:
Adjust logs during `pod install` to warn user about longer install times due to Hermes compilation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36143766
fbshipit-source-id: 0facb2e295543438dfbc46d11db1c4dc163acff9
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## 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
-->
[iOS] [Fixed] - Fix using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](26958fccf4) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](9772c6209d) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33729
This PR addresses [this comment](https://www.internalfb.com/diff/D35820848?dst_version_fbid=496290878846487&transaction_fbid=355967423221044).
It makes the CodeGen to the `outputDir` as base directory for the codegen.
Finally, it updates the unit tests accordingly.
## Changelog
[iOS][Changed] - use `outputDir` as base directory for the codegen and remove the possibility to customize the intermediate path. The generated code requires specific paths in the `#include` directive.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35935282
fbshipit-source-id: a9ad4e296efb042cf34b20db5eebb59614beb5f6
Summary:
This Diff splits the `generate-specs-cli.js` script into:
* `generate-specs-cli-executor.js`: which contains the logic to generate the code for iOS.
* `generate-specs-cli.js`: which contains the argument parsing logic and invokes the executor.
Finally it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35892576
fbshipit-source-id: 6a3205af049bf55aa4ecaf64544ebc4eb7b13f73
Summary:
This Diff splits the `generate-artifacts.js` script into:
* `generate-artifacts-executor.js`: which contains the logic to generate the code for iOS.
* `generate-artifacts.js`: which contains the argument parsing logic and invokes the executor.
Finally, it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35846674
fbshipit-source-id: 14873c3fe762606e9004a29e4a6b986bf6a8f055
Summary:
This Diff introduces some changes in the CodeGen to properly generate the types in the right folder.
## Issue
The codegen on iOS defines the output folder once, before creating the generated code.
When the code we have to generate is just a TurboModule (TM) or a Fabric Component (FC), this mechanism works properly.
However, if a library has to generate both TM and FC, actually using the library type `all`, all the code is generated using the TurboModules' output folder.
(**Note:** Android only works in this way)
This generates invalid code because all the FC's `#import` directives assumes that the code is generated in the FC output path which, in this case, is not.
## Solution
The adopted solution moves the responsibility to decide where the files has to be generated to the CodeGen step instead of in the preparatory phases.
The two paths are precomputed in the `generate-artifacts.js` script (the entry point for the CodeGen) and they are passed to all the scripts that requires them.
Once they reach the `RNCodegen.js` file, the generators creates the files and save them in the proper paths.
## Changelog
[iOS][Changed] - CodeGen now supports the `"all"` library type.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35820848
fbshipit-source-id: ce7f5393936e2ae17f8b2c970f6a011d27f641f2
Summary:
This PR adds a step in the iOS legocastle script to run the ruby tests in the cocoapods folder.
These tests are executed before the pod installation step: this because we would like to fail as fast as possible in case of issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36006781
fbshipit-source-id: 8afbc1ccc751d2dc736bdc23ec382ebd7b5c7f4f
Summary:
This Diff prepares a set of dummy tests to make sure that our infra supports tests in ruby.
It also adds a scripts in the `__tests__` folder which can be invoked to run all the tests. The script performs a discovery of all the tests in the cocoapods folder.
Next steps will configure Sandcastles and CircleCI.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35968556
fbshipit-source-id: b8bf23d30dc5358ab603e396cce1c6639dd0f567
Summary:
This PR reestablish the WebSocketTest in CI which is making the `test_ios_unit` fail.
**Note:** the test_ios_unit is actually running integration tests...
## Changelog
[iOS] [Changed] - Fix the test_ios_unit test
Pull Request resolved: https://github.com/facebook/react-native/pull/33721
Test Plan: The CI of this PR is green. 😬
Reviewed By: cortinico
Differential Revision: D36002823
Pulled By: cipolleschi
fbshipit-source-id: 20eeb08bfd02658ad6579085241f81654f74c1af
Summary:
During the release of .69, we (fortmarek and me) discovered a couple of bits that needed
some intervention.
- `sdks/.hermesversion` was gitignored, so we could not commit that.
- `scripts/bump-hermes-version.js` was not executable, so we had to chmod +x to
make it runnable.
Here I'm fixing it.
Changelog:
[Internal] [Changed] - Fix release infrastructure failures discovered during .69 release
Reviewed By: cipolleschi
Differential Revision: D36003808
fbshipit-source-id: c4d82ed5e2c63988699035ac84b0e87ed8894540
Summary:
If Hermes is enabled, it will be built from source instead of using the CocoaPods hermes-engine pod.
Changelog:
[iOS] [Changed] Build Hermes from source when Hermes is used
Reviewed By: cortinico
Differential Revision: D35693945
fbshipit-source-id: eadc638106180b183fd6d1e2a272dc3df66fa8b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33672
This pr adds a parameter to the `create-artifacts.js` script to accept the path to a node executable, falling back to `node` in case the parameter has not been passed.
Then, it passes the NODE_BINARY to the script in the `script_phases.sh` script.
This PR decouples the `node` environment from the system one and fixes a build issue in the new architecture when the environment has no `node`
## Changelog
[iOS][Changed] - Update CodeGen scripts to accept custom node executable
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35748497
fbshipit-source-id: 41b102de6427d6ef0ba1f8725f4b939d3b8c63db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33674
## Issue
In D35317070 (0480f56c5b) we introduced a way to configuring the Xcode environment via he `.xcode.env`, falling back to the old `find-node-for-xcode.sh` behavior in case of a misconfiguration.
Unfortunately, there were an issue with the new architecture for which the pods were not able to locate the `find-node-for-xcode.sh`, crashing while building the new architecture.
## Solution
This Diff solves the issue in two steps:
1. it exposes to the project the REACT_NATIVE_PATH like Android does here: D35451821 (f8d7e0a968)
2. it leverages this new variables to reach the script
## Changelog
[iOS][Changed] - Fixed the fallback behavior when the `.xcode.env` file is missing, actually using the old `find-node-for-xcode.sh` script
Reviewed By: dmitryrykun
Differential Revision: D35779165
fbshipit-source-id: 393ef9a0b98d32d9cf226f7d109fdefd772e5120
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33673
This PR solves a TODO in a script that required a link to the documentation on the website.
## Changelog
[iOS][Changed] - Adding a link in a message for the users.
Reviewed By: cortinico
Differential Revision: D35742810
fbshipit-source-id: b7416a5bead5fa525ca69f05391b307195f5c987
Summary:
there are build errors happened when in [`generate_multiple_pod_projects`](https://blog.cocoapods.org/CocoaPods-1.7.0-beta/#multiple-xcodeproj-generation) mode and fabric is on. since we have multiple pod projects, there are something breaks.
### `-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm`
because `installer.pods_project` is targeting `Pods.xcodeproj` but not `React-Core.xcodeproj`. we should use ` installer.target_installation_results.pod_target_installation_results` to deal with `generate_multiple_pod_projects` mode.
### fatal error: 'CompactValue.h' file not found
```
In file included from /path/to/react-native/packages/rn-tester/build/generated/ios/react/renderer/components/rncore/Props.cpp:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Codegen/react/renderer/components/rncore/Props.h:13:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/ViewProps.h:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/YogaStylableProps.h:10:
/path/to/react-native/packages/rn-tester/Pods/Headers/Public/Yoga/yoga/YGStyle.h:16:10: fatal error: 'CompactValue.h' file not found
#include "CompactValue.h"
^~~~~~~~~~~~~~~~
1 error generated.
```
`Props.cpp` -> `YogaStylableProps.h` -> `YGStyle.h` -> `CompactValue.h`
[`CompactValue.h` is internal private header for Yoga pod](4eef075a58/ReactCommon/yoga/Yoga.podspec (L54-L56)) where `React-Codegen` project cannot access to.
~there are some solutions toward this problem. one way is to make other yoga headers as public headers. i am not sure whether this solution would introduce any side effects. so i only make necessary projects to search yoga private headers.~
Update: a solution is to expose all yoga headers publicly. however, CocoaPods will put all public headers to module umbrella header. this will break YogaKit (swift) integration because swift module doesn't support c++. my pr is trying to expose all yoga headers to `$PODS_ROOT/Headers/Public/Yoga/yoga`, but use custom `module_map` to control which headers should be exposed to the swift module. CocoaPods's custom module_map has some limitation where cannot well support for both `use_frameworks!` mode and non use_frameworks! mode. there's a workaround to use `script_phase` copying the umbrella header to right place.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `generate_multiple_pod_projects=true` and Fabric is on
Pull Request resolved: https://github.com/facebook/react-native/pull/33381
Test Plan:
verify with rn-tester
1. add `generate_multiple_pod_projects`
```diff
--- a/packages/rn-tester/Podfile
+++ b/packages/rn-tester/Podfile
@@ -5,7 +5,7 @@ platform :ios, '11.0'
# Temporary solution to suppress duplicated GUID error.
# Can be removed once we move to generate files outside pod install.
-install! 'cocoapods', :deterministic_uuids => false
+install! 'cocoapods', :generate_multiple_pod_projects => true, :deterministic_uuids => false
USE_FRAMEWORKS = ENV['USE_FRAMEWORKS'] == '1'
```
2. pod install and build rn-tester from xcode
Reviewed By: cortinico
Differential Revision: D34844041
Pulled By: dmitryrykun
fbshipit-source-id: 93311b56d8e44491307a911ad58442f267c979eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33546
This Diff does 2 things:
1. Removes all the remnant of the `find-node.sh` script. This allows React Native to stay agnostic from any other node manager
2. Introduces a way for the developers to specify which `node` executable they want to use, through a simple `.env` file.
## Changelog
[iOS][Changed] - This PR removes the `find-node.sh` scripts and replaces it with an `.xcode.env` file that is sourced by the script phases that needs it. The `.xcode.env` file is versioned: to customize a local environment, an unversioned `.xcode.local.env` can be used.
Reviewed By: cortinico
Differential Revision: D35317070
fbshipit-source-id: 4b400ba56aa2d574db563fa67b2008e1ddde1c59
Summary:
Fix CircleCI build for test_ios_rntester.
Broken due to [this commit](fefa7b6ac8) after adding dev tools profiler.
## Changelog
[Internal] [Fixed] - Fix rn tester app CI
Pull Request resolved: https://github.com/facebook/react-native/pull/33585
Test Plan: CI should be green.
Reviewed By: neildhar
Differential Revision: D35462642
Pulled By: cortinico
fbshipit-source-id: dbcb0a7e2e58fac1c77b2dbe4b833812175dc87c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33539
As we now provide `hermes-executor-debug` OR `hermes-executor-release` based on which version of RN we're building, we need to provide a variant aware AAR.
Changelog:
[Internal] [Changed] - Setup multi-variant publishing for React Native Android
Reviewed By: ShikaSD
Differential Revision: D35289444
fbshipit-source-id: ffccd2089dc2eb50ea8c08ed10d8fd9816f9efb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33538
This Diff is a revert of this other diff: D34352049 (802b3f778b).
Following a discussion with the Open Source Community, the removal of `find-node.sh` script will break some configurations that leverages different node managers.
The landed diff will block the release of version 0.69, that's the reason why we are reverting it.
However, we still want to abstract RN from knowing which node manager the user is going to use. After discussing with the community, we will deprecate the usage of this script and we will move toward a configurable `.xcode.env` file that developers can configure on their own. The task for this is tracked here: T115868521.
## Changelog
[Internal][Removed] - Reintroduce the old `find-node.sh` script to prevent broken builds for some users
Reviewed By: cortinico
Differential Revision: D35280778
fbshipit-source-id: 7a0b269af207e13998fd85c0c4839e75028cda65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33549
When building Hermes from source, use arbitrary hermes-engine.podspec to ensure correct Hermes tag is used by CocoaPods.
Without this change, CocoaPods will check out the `v0.11.0` git tag from the `facebook/hermes` git repository.
Ideally, this change should be done in the original `hermes-engine.podspec` in `facebook/hermes`. For now, use the arbitrary copy until the canonical Pod has been updated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35300595
fbshipit-source-id: be4b1225eb2c2a88958cd9e5e98cb8efed343bad
Summary:
Print logs during `pod install` to clarify when Hermes is being used with RNTester and/or iOS React Native apps.
This changeset should not result in any change to the behavior of `pod install`, other than adding logs to CocoaPods' stdout.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294993
fbshipit-source-id: 55b6115d9f49c311c34ad3cb07346b2f97adcbf9
Summary:
When downloading Hermes from source on Circle CI, the process will fail because Circle CI macOS machines do not have wget installed.
Since curl can serve the same purpose and it is already part of the installed software on macOS machines, we can use curl in place of wget.
This change ensures Hermes can be built from source on Circle CI jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294868
fbshipit-source-id: bb099b603ef64205d45b833882852b2f4d6060ca
Summary:
In https://github.com/facebook/react-native/blob/main/scripts/update-ruby.sh#L61
```bash
bundle lock
```
is called which creates a Gemfile.lock in the rn root. This file should be in the git add files list along with the other files that get updated by that script.
## Changelog
[Internal] [Fixed] - Added Gemfile.lock to git add files when calling update-ruby.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/33484
Test Plan: Call update-ruby.sh with or without this patch. Without this patch, the Gemfile.lock will not be staged, with this patch, the Gemfile.lock will be staged.
Reviewed By: GijsWeterings
Differential Revision: D35118250
Pulled By: cortinico
fbshipit-source-id: 80f2c7fad6fbc3f09697988dcc20f7ac94a21473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
Undoing the recent change that enabled Hermes to be built from source by default.
Building Hermes from source now requires the use of the BUILD_HERMES_SOURCE envvar, again.
To be re-enabled shortly.
Pull Request resolved: https://github.com/facebook/react-native/pull/33478
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35100459
fbshipit-source-id: ec83fcdf2432c689b0c02f86fbabcc8625975d51
Summary:
Remove BUILD_HERMES_SOURCE gate and default to building Hermes from source on iOS when Hermes is enabled.
Changelog:
[iOS][Changed] - When Hermes is enabled, the Hermes Engine will be built from source instead of using the pre-built `hermes-engine` CocoaPod.
Reviewed By: cortinico
Differential Revision: D34911987
fbshipit-source-id: 9d6d49498a23f6dae0b97c9f80c689b654db11bd
Summary:
GitHub's tarball endpoint does not provide a last-modified header, which keeps us from using wget's `--timestamping` flag to avoid re-downloading Hermes unnecessarily.
To work around this, we use the commit sha for the requested Hermes version - whether that is Hermes from trunk (`main` branch) or Hermes from a tagged commit - as the filename for the hermes tarball. Then it's as simple as performing a filesystem check to determine if we need to re-download the Hermes tarball. This should work as expected because any changes will result in a different commit SHA.
Additionally, a symbolic link to the pre-compiled HermesCompiler is created after the Hermes tarball is extracted. The result of this is that hermesc won't be recompiled when the `hermes-engine` Pod is built.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D34834139
fbshipit-source-id: 4c49bc11f3551ec8d6cca58fcceccad48ad4a10f
Summary:
For the same reason we don't keep a yarn.lock or Podfile.lock, we shouldn't be keeping a Gemfile.lock in the template. The user will generate this on his own pulling in the current dependencies with the constraints in Gemfile. No need to lock to a specific version.
cc barbieri (author of https://github.com/facebook/react-native/pull/32303)
cc ravirajn22 (for raising the issue)
## Changelog
[iOS] [Fixed] - Remove Gemfile.lock from template
Pull Request resolved: https://github.com/facebook/react-native/pull/33469
Test Plan: no test plan
Reviewed By: javache
Differential Revision: D35074105
Pulled By: cortinico
fbshipit-source-id: 47d1b92329f1d55d4a0adbacbc7e5e45f9d957e0
Summary:
When upgrading `react-native`, the version `RCT-Folly` defined [here](https://github.com/facebook/react-native/blob/main/third-party-podspecs/RCT-Folly.podspec) can change. If that happens, if you run `pod install` after `yarn install`, you will get a similar error to this:
```
[!] CocoaPods could not find compatible versions for pod "RCT-Folly":
In snapshot (Podfile.lock):
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
In Podfile:
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on
RCT-Folly (= 2021.06.28.00-v2)
```
This error occurs because `Cocoapods` does not update pods that point to a local podspec. Locally, you could resolve this issue by running `pod update RCT-Folly --no-repo-update`. On the CI, you have to do a clean checkout (in case you cache the `Pods` folder which we do). All of this makes upgrading `react-native` painful - for the whole community and for us shopify
There are other users who have struggled with this, such as [here](https://github.com/facebook/react-native/issues/32423). The suggestion there is to delete `Podfile.lock` which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing.
To mitigate these issues, `react_native_pods.rb` automatically marks `RCT-Folly` as changed in the [detect_changes_with_podfile method](https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/lockfile.rb#L289) from `Pod::Lockfile` if the version in `node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` and `Pods/Local Podspecs/RCT-Folly.podspec.json` mismatch.
Instead of automatically updating the local podspec (in `Pods/Local Podspecs` directory) we could also:
a) integrate `RCT-Folly` as a local pod (such as `React-Core` and others)
b) integrate `RCT-Folly` as an external dependency (going through Cocoapods' centralized repository)
I don't have enough context on why `RCT-Folly` is bundled the way it is, so I am open to suggestions here.
## 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
-->
[iOS] [Fixed] - Fix `pod install` when `RCT-Folly` version has been updated.
Pull Request resolved: https://github.com/facebook/react-native/pull/32659
Test Plan:
I have created a [repository](https://github.com/fortmarek/react-native-upgrade-reproduction) where you can reproduce the issue. You can simply:
1) clone the repo (`git clone https://github.com/fortmarek/react-native-upgrade-reproduction`)
2) Run `yarn install && cd ios && pod install`
3) Change `react-native` version in `package.json` to `0.66.3`
4) Run again `yarn install && pod install`
5) Observe error
To test the fix, you can then:
1) copy-paste the `react_native_pods.rb` file from this branch to `react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb`
2) run `pod install` again
This time, the `pod install` command should succeed.
Reviewed By: sota000
Differential Revision: D32720758
Pulled By: cortinico
fbshipit-source-id: 940db9c9f0530f896e47b676dec46bc93cea0085
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33439
This allows us to toggle the publishing of prefab if the `REACT_NATIVE_HERMES_SKIP_PREFAB`
env variable is set. With this we can control how big is the .aar of hermes-engine, reducing
the size from ~200Mb right now to 8Mb.
Changelog:
[Internal] [Changed] - Disable prefab publishing if REACT_NATIVE_HERMES_SKIP_PREFAB is set
Reviewed By: ShikaSD
Differential Revision: D34929265
fbshipit-source-id: eb710b72ee4e17ac04c2924ffdac7a542928e9f8
Summary:
This re-applies Consider relative to pwd installation root when looking for files in rn module via cocoapods by danilobuerger
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33427
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: cortinico
Differential Revision: D34890926
Pulled By: dmitryrykun
fbshipit-source-id: f7adc6196874822d5ff38f275414f529d385f2ea
Summary:
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33399
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: ShikaSD
Differential Revision: D34784966
Pulled By: dmitryrykun
fbshipit-source-id: d6d5e71bc2fcd32f2cd60a498f39e6f772fc9005
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413
This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34723341
fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
## 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
-->
[iOS] [Fixed] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
Downloads a tarball of the Hermes source code when `pod install` is run.
If the current release is pinned to a Hermes tag, it will use that specific tag, otherwise the latest Hermes commit will be used.
# Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D34629595
fbshipit-source-id: 5f36af4a43bc2d137dfd702082558ab9d0191140
Summary:
Changelog: [Internal] This diff add support of relative paths in `app_path` argument of `use_react_native` function.
Ruby's `relative_path_from` function requires both paths to be either relative or absolute. I added `realpath()` call that converts any path to absolute.
Reviewed By: ShikaSD
Differential Revision: D33311728
fbshipit-source-id: 393a7b4f0eb26831f4d9f4cec8ec180b41cad580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33209
Downloads Kotlin compiler JARs with Buck before starting docker build. This solution is slower than checking in JARs directly, but it allows to keep lighter size of the repo for people who want a complete checkout.
Changelog: [Internal] - Update CI build to download Kotlin jars for buck
Reviewed By: cortinico
Differential Revision: D34582932
fbshipit-source-id: 290398579ce2a4d57c7af318c66526689db6073c
Summary:
React Native releases that bundle the Hermes source code will have a `sdks/.hermesversion` file which indicates the specific git tag used when pulling the Hermes source code.
This script provides a method for release coordinators to specify which Hermes tag will be used in a given release. The Hermes tag should already exist on the `facebook/hermes` repository on GitHub, although this script makes no determination as to its validity.
# Changelog
[Internal] Added new script for release coordinators
Reviewed By: cortinico
Differential Revision: D34460693
fbshipit-source-id: b2f882ba66d925034c3803aafe81de5204d9e33f
Summary:
If Hermes is enabled on a project and the envvar `BUILD_HERMES_SOURCE` is truthy, a React Native project will build Hermes from source when running `pod install`:
```
cd ios/
BUILD_HERMES_SOURCE=1 pod install
```
* Requires `cmake` and `ninja` to be installed: `brew install cmake ninja`.
* Requires a `react-native` release with Hermes source code bundled in (`scripts/publish-npm.js --include-hermes && npm pack`).
# Changelog
[Internal]
Reviewed By: cortinico
Differential Revision: D34313581
fbshipit-source-id: 4ba5f82aa6c7027fd37f1982127fc5f63d931ded
Summary:
If `--include-hermes` flag is set, the Hermes source code will be downloaded and included in the `react-native` npm package as part of the release.
Hermes will be available at `node_modules/react-native/third-party-podspecs/hermes`.
# Changelog
[Internal] Update build scripts to provide option to bundle Hermes source code
Reviewed By: cortinico
Differential Revision: D34255926
fbshipit-source-id: 76c1e9811a05a4a827ceba13e572d0ea756ac724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33146
Pull Request resolved: https://github.com/facebook/react-native/pull/33145
It removes the find node script that introduced complexity in the system.
## Changelog
[Internal][Removed] - Removed the old `find-node.sh` script which was only adding complexity without doing nothing really useful.
Reviewed By: cortinico
Differential Revision: D34352049
fbshipit-source-id: 9ba4275c3863a1ae4bc2b4e2f1694a7ac994cdc8
Summary:
Running `test-manual-e2e.sh` from any folder other than the repo root results in errors regarding files not existing, that's because we're not taking into consideration the path from where the script is invoked. This PR updates it so that we get the absolute path of the script and then use it to get the parent directory and `cd` to the repo root folder.
Closes https://github.com/facebook/react-native/issues/32999
## Changelog
[Internal] [Fixed] - fix access to relative paths when invoking `test-manual-e2e.sh` from folders other than the repo root
Pull Request resolved: https://github.com/facebook/react-native/pull/33000
Test Plan:
1. Clone this repo
2. Navigate to the rn-tester folder `cd packages/rn-tester/`
3. Run `../../scripts/test-manual-e2e.sh`
4. Select RNTester, Android and Hermes
https://user-images.githubusercontent.com/11707729/151730441-18bc37de-0224-4f5e-a2fe-408e3ace5c1f.mov
Reviewed By: ShikaSD
Differential Revision: D33915561
Pulled By: cortinico
fbshipit-source-id: 66f2d1ebee50bba3fe884d6346ea08ffced47a96
Summary:
Since 0.64, local code in `Bundle React Native code and images` step for iOS is not enough anymore.
This add support for [fnm](https://github.com/Schniz/fnm) that is widely used this days.
## 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] [Added] - Support fnm when detecting node binary
Pull Request resolved: https://github.com/facebook/react-native/pull/32890
Test Plan: I use fnm & it's working. Tested this code via patch-package.
Reviewed By: christophpurrer
Differential Revision: D33766842
Pulled By: cortinico
fbshipit-source-id: 77bbda2c7742de9ec64e6faa9a3526d3997bb4aa
Summary:
The path to `Time.h` is currently hard-coded and does not take into
consideration the `--project-directory` flag when running `pod install`.
## Changelog
[iOS] [Fixed] - Fix `Time.h` patch not being applied when running `pod install --project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32961
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
../scripts/xcodebuild.sh ios/Example.xcworkspace build
```
Reviewed By: christophpurrer
Differential Revision: D33748789
Pulled By: lunaleaps
fbshipit-source-id: b125734eba30e552ae139e7ecd4e634c8fa1bcd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32946
Changelog: [Internal]
This fixes a bug where config file dir was incorrectly and breaks the codegen which runs when building an app.
Reviewed By: dmitryrykun
Differential Revision: D33724558
fbshipit-source-id: 0c04c1d41f2fb9b958da64fa414746695cea60cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32923
As our Flipper version is quite old, let's bump it to one of the latest stable: 0.125.0
This required to update also the following:
- Flipper-Folly to 2.6.10 - This was needed as I aligned the versions to https://github.com/facebook/flipper/blob/v0.125.0/react-native/ReactNativeFlipperExample/ios/Podfile
- OpenSSL-Universal to 1.1.1100 - This was required with the `pod update` command
I've picked 0.125.0 as 0.127.x and following are crashing on Android
and will potentially require a bump of the NDK to r23:
See: https://github.com/facebook/flipper/issues/3245
Changelog:
[General] [Changed] - Bump Flipper to 0.125.0
allow-large-files
Reviewed By: mdvacca
Differential Revision: D33583090
fbshipit-source-id: 2a2020c3213273087ec4a152076f846e35e275c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32925
Changelog: [internal] I was testing with some sample proect without the codegen discovery, and I found a code path that doesn't work due to the escape charactors left.
Reviewed By: christophpurrer
Differential Revision: D33670881
fbshipit-source-id: 94bd4f0eea28ebf86001381f08e6ddbff7213793
Summary:
The CI is currently failing with:
```
Error extracting tarball /tmp/cache1419328940 : tar: root/.cache/yarn: Cannot mkdir: Permission denied tar: root/.cache/yarn/v6
```
The problem is that we're sharing the Yarn cache between two jobs (`test_js` and `test_ios_unit_jsc`) which are executed on two difference executors (a Machine vs a Docker container).
I've update the cache key to be `v5-yarn-cache-{{ .Environment.CIRCLE_JOB }}-{{ arch }}-{{ checksum "yarn.lock" }}` so the job name is accounted when computing the Cache Key.
Moreover the `test_js` test was also failing on `flow check` as one of the library we depend on (`resolve`) added a test with a malformed JSON. I'm fixing this failure as well so the CI is back green.
## Changelog
[Internal] - Updating Yarn Cache path to fix broken CI
Pull Request resolved: https://github.com/facebook/react-native/pull/32834
Test Plan: Verified that the external CI is green: https://github.com/facebook/react-native/pull/32834
Reviewed By: lunaleaps
Differential Revision: D33453702
Pulled By: cortinico
fbshipit-source-id: 52bf42db583eaf6aa913f1bb164566f8c3563d36
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32769
Changelog: [Internal] Re-purpose bump-oss-version to guide releaser to correctly tag the release and trigger relevant CircleCI jobs
Reviewed By: sota000
Differential Revision: D33121691
fbshipit-source-id: 739f920cd9a04dfb436aff1abe9a05a51df4c32c
Summary:
Changelog: [Internal] Update the comments in publish-npm script to changes in release workflow and leverage `isTaggedLatest` utility.
A lot of this information will be moved to the Release wiki on Github
Reviewed By: ShikaSD
Differential Revision: D33110407
fbshipit-source-id: b01a555a3eed6e505a3b0ad220a0c2c54459ab03
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32757
Changelog: [Internal] - Update release automation to still be manually triggered as from discussion: https://github.com/reactwg/react-native-releases/discussions/7
A releaser needs to do the following on a release branch like `0.99-stable`:
* For an initial release branch cut:
* Tag the head of the branch `git tag publish-v0.99.0-rc.0`
* `git push origin 0.99-stable --follow-tags`
* For cherry-picks on the pre-release:
* Make the picks on `0.99-stable`
* Tag the head of the branch `git tag publish-v0.99.0-rc.1`
* `git push origin 0.99-stable --follow-tags`
* For promoting pre-release to stable with intention of making this the `latest` npm version:
* Tag the head of the branch `git tag publish-v0.99.0`
* Tag the head of the branch `git tag latest`
* `git push origin 0.99-stable --follow-tags`
Follow-up diff to make this codified via a script
Reviewed By: sota000
Differential Revision: D33101594
fbshipit-source-id: 74b065229a3705fccbe1a25ed7ece4a28d9aa76d
Summary:
Changelog: [Internal] Remove un-necessary package installs which was using `npm install flow-bin --save-dev` which was wiping out our `node_modules` from the circleCI yarn install.
It was un-necessary as we already have `flow-bin` as a dependency in our current set-up.
In addtion, we were running `npm pack` without properly copying over our package.json dependencies (which occurs in `prepare-package-for-release`) for a consumable react-native package.
This may not have caused issue but technically we were creating an "incomplete" package to do our e2e testing on.
Reviewed By: charlesbdudley
Differential Revision: D33197965
fbshipit-source-id: 6583ef1f8e17333c0f27ecc37635c36ae5a0bb62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32777
Changelog: [iOS][Added] Added the new architecture support to the new app template. To apply this change to your project, you will need to update your Podfile. You can try it by using "RCT_NEW_ARCH_ENABLE=1 pod instal" command which updates necessary C++ flags and enable the new codegen discovery required for the new architecture. As context, We've modified the iOS template to have code required to enable the new architecture (aka Turbo modules and fabric / renderer) which requires updating AppDelegate. We also added the support in RNTester as well. We will be sharing more documentation about the new architecture.
Reviewed By: dmitryrykun
Differential Revision: D33154825
fbshipit-source-id: a46b98308e9d29780b6a5245e8faa8be1e257802
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32764
Changelog: [Internal] This diff refactors react_native_pods.rb so that it's a bit more readable/maintainable.
With the intorduction of the codegen discovery script, we have two script phases that shares some code. I've factored it out of the main file and wrote a snapshot test so that it's easier to see the output script file.
Reviewed By: cortinico
Differential Revision: D33045541
fbshipit-source-id: 9c80b5d7e11862cc44275e36882487a7d63e8125
Summary: Changelog: [internal] Adding snapshots for script_phases. These snapshots are taken from working scripts.
Reviewed By: cortinico
Differential Revision: D33045627
fbshipit-source-id: fbc1e005954cd185fb5f9b48c55a073ad9d5523a
Summary: Changelog: [internal] Move script_phases script out of react_native_pods.rb so that it's easier to review/debug.
Reviewed By: cortinico
Differential Revision: D33054423
fbshipit-source-id: 460de83a38959a1e45e37f8eda7fe364026fb571
Summary: Changelog: [internal] Fixing a couple of bugs when running with USE_CODEGEN_DISCOVERY.
Reviewed By: mdvacca
Differential Revision: D33115937
fbshipit-source-id: bb770b406b6dbebfefccac488a7c40caaafa6ca6
Summary:
The generated fabric components provider includes fabric headers that won't be included when building without fabric.
This checks the fabric enabled param and skip generating the provider in that case.
## Changelog
[iOS] [Fixed] - Don't generate fabric component provider if fabric is not enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/32761
Test Plan: Test that an app with codegen discovery enabled now builds properly with fabric disabled.
Reviewed By: ShikaSD
Differential Revision: D33111968
Pulled By: sota000
fbshipit-source-id: 3704e11b1e614369f1c652e8cb1acba51cf7ffad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32755
Changelog: [Internal] Make the Reat-Codegen script_pahses only triggered when the in-app libaries are modified. When other libraries like ones inside node_modules are modified, you'll need to run `USE_CODEGEN_DISCOVERY=1 pod install` to update the source.
Reviewed By: cortinico
Differential Revision: D33007986
fbshipit-source-id: 0546bbd1d57cd54a482d71b43b296484de60a92c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32731
Changelog: [internal] Trigger codegen discovery script when building React-Codegen so that users won't have to run pod install every time modifying fabric / turbomodule library.
Reviewed By: cortinico
Differential Revision: D32979871
fbshipit-source-id: 18550b6b010a9a2b8b7513aaa3b6a7322ea83eff
Summary:
Co-Authored-By: William Bell <williambell9708@outlook.com>
If one of the pods has no IPHONEOS_DEPLOYMENT_TARGET, the M1 postinstall workaround script fails. This commit updates the code to handle this special case.
## 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
-->
[iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround failing when one of the Pods has no IPHONEOS_DEPLOYMENT_TARGET set
Pull Request resolved: https://github.com/facebook/react-native/pull/32746
Test Plan: https://github.com/reactwg/react-native-releases/discussions/6#discussioncomment-1791520
Reviewed By: charlesbdudley
Differential Revision: D33063717
Pulled By: lunaleaps
fbshipit-source-id: f45bc47c85e42ffb5c37a277fbedd48a729ef5fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32749
Changelog: [Internal] Move the use_react_native_codegen_discovery call to use_react_native.
Found out that pre_install doesn't get invoked until all podspecs are read. This wouldn't work because I want use_react_native_codegen_discovery to generate React-Codgen podspecs.
I also think it's better to have less logic in Podfiles as it's hard to update once users set it up.
Reviewed By: cortinico
Differential Revision: D33054318
fbshipit-source-id: 6d62be454610c8a1d55988fe376ee3f187510a36
Summary:
Changelog: [internal] Fixes the output path for the fabric provider.
The old path wouldn't work when the pod installation path is not the same as the app dir.
Reviewed By: cortinico
Differential Revision: D32911493
fbshipit-source-id: 74a8481a2e8397024645d7daff2897e4b0b5454e
Summary:
React-native Xcode build steps (such as "Build JS Bundle") rely on `find.node-sh` to find the correct node binary, using nvm if present. We do this because Xcode may run build steps in a fresh shell environment, presumably for repeatable builds.
This PR fixes `find-node.sh`, to respect any `.nvmrc` file that may be present in the build environment.
Today: `find-node.sh` will set the shell environment to the system node version, and ignores any `.nvmrc` the project may provide to pin node for repeatable builds. By ignoring `.nvmrc`, node versions may differ depending on system environment — between developer laptops, or between developer and CI environments. 😞
This problem has been been noticed before in https://github.com/facebook/react-native/issues/8887
### Should this fix happen upstream?
Unfortunately this nvm behavior [is intended](https://github.com/nvm-sh/nvm/issues/2053), for backwards compatibility
## 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
-->
[iOS] [Fixed] - find-node.sh now respects .nvmrc
Pull Request resolved: https://github.com/facebook/react-native/pull/32712
Test Plan:
Before:
```bash
# nvm isn't loaded
$ which nvm
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v17.0.1
```
After:
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v16.13.0
```
After (no .nvmrc, should preserve previous behavior):
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ source ./scripts/find-node.sh
$ nvm ls|grep default
default -> v14.17.1
# Expected: v14.17.1
$ node --version
v14.17.1
```
Reviewed By: sota000
Differential Revision: D32889629
Pulled By: ShikaSD
fbshipit-source-id: 527384055e303a87bad43413fb66a7fd117d1a63
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary: Changelog: [Internal] Adding an option in RN Tester to enable the new codegen discovery option where it uses generate-artifacts.js to codegen native files. It also updates generate-artifacts.js to support the case where react-native is not within node_modules. It also updates the option name for rn-demo-app.
Reviewed By: cortinico
Differential Revision: D32777912
fbshipit-source-id: f2b76fa61573e3d4507a9f16f8243ac7ca006900
Summary:
Changelog: [Internal] Revert --sourcemap-output argument
Reverting on main from discussion from the 67 release:
https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1705266
Original commit changeset: 0c2d98746b36
Reviewed By: GijsWeterings
Differential Revision: D32734743
fbshipit-source-id: cc3130581d01bdcdc9f5d483161ae9506fdbf7b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32678
In D32420306 (3d8b5a35f9) (3d8b5a35f9), I added a phase which uses a codegen, but it assumed that the codegen package has already been built. This diff fixes the issue where it checks and build the codegen packaage.
I also reverted the change that I made for the circle CI test since it now builds the codegen when running pod install.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D32707588
fbshipit-source-id: a287ff96e8123833da093228fe60e2069884eb45
Summary:
Changelog: [Internal] Update CircleCI to auto-deploy release branch on push
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff updates the relevant CircleCI workflows
Reviewed By: sota000
Differential Revision: D32702420
fbshipit-source-id: e20cdeb53eb4a8ce7e54e083e3e14bd89e11b789
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] Copy over universal (across dry-run, nightly, release) work in `bump-oss-version` script
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `set-rn-version` script referenced by extracting it out of `bump-oss-version`
Reviewed By: sota000
Differential Revision: D32556608
fbshipit-source-id: 6c2868c01ddd930375279a5105bcd0d447f65734
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`.
I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`.
See also: this discussion post by mikehardy https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523
## 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
-->
[iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Pull Request resolved: https://github.com/facebook/react-native/pull/32633
Test Plan:
### Test (failing before this patch, passing after this patch)
1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package
2. `npx react-native init myrnapp`
3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`))
4. Compile the app.
Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds
Reviewed By: fkgozali
Differential Revision: D32638171
Pulled By: philIip
fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
Summary:
Custom metro port not working without exporting variables from `.packager.env`
## Changelog
[General] [Fixed] - Fix support for custom port
Pull Request resolved: https://github.com/facebook/react-native/pull/32666
Test Plan: run `react-native run-android --port=8082` and `react-native run-ios --port=8082`
Reviewed By: yungsters
Differential Revision: D32694233
Pulled By: cortinico
fbshipit-source-id: 42e803d56b83608024b901d2a3024733ed7099b7
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
This PR add [volta](https://volta.sh/) support to find-node.sh for use by `scripts/react-native-xcode.sh`, `scripts/generate-specs.sh`, etc.
## Changelog
[iOS] [Added] - add volta support to find-node.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32611
Test Plan:
Manually tested with volta installed node (and [relevant change](https://docs.volta.sh/guide/understanding#managing-your-project) added to the project's package.json). Without this patch, the `Bundle React Native code and images` Build Phase fails, with it, it succeeds.
Tested with both `curl https://get.volta.sh | bash` installed and `brew install volta`. One check works for both because the `node` shim will always be installed to the same location (and the required environment variable exports are the same also)
Wasn't sure if you'd want the package.json change applied to rn-tester? Shouldn't affect people who don't use volta. Shout if you want me to add it to this PR.
Reviewed By: cortinico
Differential Revision: D32498267
Pulled By: yungsters
fbshipit-source-id: 93ee187bd2178bfcd8f9009a1a0668c6f5583aa3
Summary:
This diff supports monorepo/custom configuration where node_modules may not be located under app_root.
The default (RN_root, '..') should support most cases, but I also added an option to provide a custom location for users to set.
Changelog: [internal]
Reviewed By: ShikaSD
Differential Revision: D32469957
fbshipit-source-id: 6b8a6c775c21bde72ef542e34973701d698f678f
Summary:
This diff adds a support to generate ThirdPartyFabricComponentProvider when codegen discovery isn't enabled. This functionality will be removed when we start using the new way of generating code as a default.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D32420306
fbshipit-source-id: 219bcdf6cb186196ca62e651086dedab485b063e
Summary:
There will still be a case where this script is used when fabric is disabled. This diff adds the flag so that whether to generate fabric components can be controlled by the user.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32380881
fbshipit-source-id: 786931848b1eca5015c8f58f4361b395c8d341cc
Summary:
This moves the output location for turbo modules from build/generated/ios/react/renderer/components/ to build/generated/ios/ so that the third party modules can use Spec/Spec.h to import. In the future we might use the same folder structure for both components and modules.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D32340162
fbshipit-source-id: 6ad7c8ae92e072cd26e44b47914afa33618acbcb
Summary:
Changelog: [Internal]
* Sets a default custom reporter in `scripts/packager.sh` that redirects Metro's logs to a JSON file when the `RCT_PACKAGER_LOG_PATH` environment variable is set. Otherwise we use Metro's `TerminalReporter`, [like the CLI does by default](0993f62786/packages/cli-plugin-metro/src/commands/start/runServer.ts (L124)).
* Modifies `scripts/launchPackager.command` to write logs to `$RCT_PACKAGER_LOGS_DIR` (and in particular use the JSON reporter) if this environment var is set.
* Uses [`open -n`](https://ss64.com/osx/open.html#:~:text=Open%20a%20new%20instance%20of%20the%20application) to execute `launchPackager.command` from Xcode, so that environment variables are reliably passed to the script even if a Terminal process is already running.
Reviewed By: yungsters
Differential Revision: D32295290
fbshipit-source-id: 4d783e1f94d122d3a35c104b2b02dbfaf8e1a1a3
Summary:
Adds a phase to generate-artifacts.js to generate the third party components provider for fabric. The output path needs to align with where the rest of generated files go (the work is wip).
Changelog:[internal]
Reviewed By: hramos
Differential Revision: D32128834
fbshipit-source-id: 8721b8a19bcf01bb388a293ce17162b4e578a72a
Summary:
NOTE: Second attempt at merging https://github.com/facebook/react-native/pull/32486 (D32080994 (25d4cb98b0)).
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan: See `react-native-oss-ios` Sandcastle job succeed.
Reviewed By: fkgozali
Differential Revision: D32256761
Pulled By: yungsters
fbshipit-source-id: c7f32b72287018f070910b26aad02aa0adf4a61f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32543
Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version
Context:
* There are two types of tags, git and npm, they are unrelated.
* When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version.
* When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version.
* npm and git's `latest` tag should always point to our most recent stable version
This change:
* Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest"
* If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag
* Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`.
* This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version.
Reviewed By: hramos
Differential Revision: D32196239
fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function
Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds
Reviewed By: hramos
Differential Revision: D32196237
fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544
Summary:
Use generate-artifacts.js script when USE_CODEGEN_DISCOVERY envvar is set to 1 at `pod install` time. Setting this envvar will disable the old codegen script.
Added `[Codegen]` prefix to all codegen log output.
Note: This script is not ready for production use at the moment.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31693778
fbshipit-source-id: 25da95bdb33315ac42c6dfb40334e22ec9823cb1
Summary:
The current warning assumes the ruby binary to be single arch, but the ruby version shipping with macOS is universal `universal.arm64e-darwin20`. This PR changes the check to search for `arm64` in any position instead of just the beginning to fix false positives.
## Changelog
[iOS] [Fixed] - Fix Rosetta2 CocoaPods warning on Apple Silicon
Pull Request resolved: https://github.com/facebook/react-native/pull/32498
Test Plan:
### Before
On M1 Mac `pod install` using system ruby always yields a warning.
### After
`pod install` does not yield a warning.
`arch -x86_64 pod install` yields a warning.
Reviewed By: fkgozali
Differential Revision: D32013176
Pulled By: sota000
fbshipit-source-id: 84f517c210318b5d073d161b6849b9aee367bba6
Summary:
Running `pod install` from outside the `ios` folder fails because the
path to `React-Codegen` is wrong:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
[!] No podspec found for `React-Codegen` in `ios/build/generated/ios`
```
## 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
-->
[iOS] [Fixed] - `pod install --project-directory=ios` fails due to wrong path to `React-Codegen`
Pull Request resolved: https://github.com/facebook/react-native/pull/32489
Test Plan:
1. Verify that `pod install` still works in `/packages/rn-tester`
2. Verify that `pod install --project-directory=ios` also works:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
```
Reviewed By: lunaleaps
Differential Revision: D32158140
Pulled By: sota000
fbshipit-source-id: 98f12b0073cd911cb9de06201222d866ef7649a4
Summary:
This is a fixed version of the https://github.com/facebook/react-native/issues/32380 PR. It solves a typo, prevents variable substitution in the patch file, and moves it to a better place in the script so that CURRENT_ARCH is actually detected before checking whether to patch.
The `config.sub` included in glog is too old and does not recognize `arm64-*` as a valid arch when building. This, combined with an out of date Flipper-Glog version, results in persistent build failures on Apple Silicon machines.
p.s. i assume all the podfile lock changes were caused by me running this on an Apple Silicon Mac, and thus all the pod checksums were run against the arm64 versions of those pods rather than the normal x86_64 versions. if this is an issue I can revert the changes to that file, but it would seem to be an inevitable issue in future PR diffs...
## Changelog
- [iOS] [Fixed] - Apple Silicon builds of glog & Flipper-Glog
Pull Request resolved: https://github.com/facebook/react-native/pull/32486
Test Plan:
- Clone this branch on both an Apple Silicon- & Intel-based Mac
- Run `pod install` in `packages/rn-tester`
- Confirm that build passes successfully
Reviewed By: cortinico
Differential Revision: D32080994
Pulled By: yungsters
fbshipit-source-id: 76a7c5bba20d91905455920609c890e92bb5b980
Summary:
Make `generate-specs-cli.js` use named arguments.
Updated all `generate-specs-cli.js` callsites to make use of named arguments.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31908041
fbshipit-source-id: f2cb5967db3c3b847e1095e35e8d5d21585be27b
Summary:
D31809012 (f7e4c07c84) introduced a condition where codegen files weren't generated in a correct order so the build fails in `yarn test-ios` if it was a first time to run the command. So it broke ci/circleci: test_ios_unit_hermes.
In this diff
Pull Request resolved: https://github.com/facebook/react-native/pull/32480
Changelog: [intermal]
Reviewed By: cortinico
Differential Revision: D31953580
fbshipit-source-id: db854d6cfed8167dc4aae2667d379738bc261cfe
Summary:
I missed to push this change in the previous diff D31809012 (f7e4c07c84).
This diff adds a check so that only when fabric is enabled it include the React-graphic dependency.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D31919354
fbshipit-source-id: 0b4e7f489155f868cdf58bec3f61f309470ca0c6
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Adding an error check to make debugging easier when codegen fails when invalid library_type option is passed.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31907880
fbshipit-source-id: c1ffa6bbd7b3e4faede88da2ee8d3378fa086780
Summary:
Currently, some filtering of generated files are done in multiple places (e.g. generate-specs-cli.js, react_native_pods.rb, etc). I am introducing this arguments so that only needed files are generated for components and modules.
Changelog: [internal]
Reviewed By: hramos, cortinico
Differential Revision: D31878098
fbshipit-source-id: d2dc8f51ea14a5d0ba1548bd481814220c9ae3a2
Summary:
Fix the `scripts/update-ruby.sh` so it always use the correct [bundle config](https://bundler.io/man/bundle-config.1.html#DESCRIPTION). In the current version it wasn't using the correct configuration inside the `template/` directory, resulting in incorrect platform for `template/Gemfile.lock`.
While at that, update the gems to their latest version:
- ethon 0.14.0 -> 0.15.0
- json 0.5.1 -> 0.6.0
- zeitwerk 2.4.2 -> 2.5.1
- bundler 2.2.28 -> 2.2.29
## Changelog
No changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/32456
Test Plan:
Run `bump-oss-version.js` and see `template/Gemfile.lock` lists `ruby` as the `PLATFORM` (no diff in that line).
## References
- e18cf90d71 (r58230816)
Reviewed By: yungsters
Differential Revision: D31841524
Pulled By: charlesbdudley
fbshipit-source-id: 695c245fcb344c866afed45f747e04233e5c91e4
Summary:
Adds utility script which crawls through a React Native app's Node dependencies and, for each compatible library, generates the relevant native code artifacts.
This script is for development purposes, and is not hooked into the existing codegen integration by design.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D28915433
fbshipit-source-id: de36d3e1dc0e11aad3ca55cea5e6731db09c5377
Summary:
The new architecture generates code that needs to be included in the xcode project. This diff adds a method that will be called when calling "pod install". There will be following diffs that will add the usage of this function.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D31699330
fbshipit-source-id: 491de7f60afee69aae750bbda6a687cea2526cc0
Summary: Changelog: [Internal] Configure circleCI to comment on PR after building tarball
Reviewed By: hramos
Differential Revision: D31387660
fbshipit-source-id: 28902148cf5e2ea15320333b90a6a7fa9d553c3b
Summary:
Implement par of the discussion https://github.com/react-native-community/discussions-and-proposals/discussions/411, except the `.nvmrc` part, this includes:
- Setting `.ruby-version` in the main project and also `template/`
- Fixing the CocoaPods version with a project-level `Gemfile` and also `template/Gemfile`
- Using all `pod` executions from `bundle exec pod`, using the determined version
- Script to manage and update the ruby version
## Changelog
[iOS] [Added] - Gemfile with CocoaPods 1.11 and ruby-version (2.7.4)
Pull Request resolved: https://github.com/facebook/react-native/pull/32303
Test Plan: Build for iOS and run all CircleCI tests to see if nothing changed
Reviewed By: RSNara
Differential Revision: D31344686
Pulled By: fkgozali
fbshipit-source-id: 25c63131ca9b16d3cf6341019548e0d63bdcaefe
Summary:
Add a new -v or --to-version argument to the bump-oss-version script.
When the bump-oss-version script runs, it will use the version string that is passed in, instead of trying to infer it from the current commit. This fixes a bug in the last nightly release where the bump script used a different version string than what the publish script expected.
Nightlies now run at 20:00 hours UTC.
Changelog: [Internal]
Reviewed By: fkgozali, TheSavior
Differential Revision: D31261829
fbshipit-source-id: a9341f93c3c7bf0379aa3c5e7f345182df70f846
Summary:
Bump the version of Xcode used in internal and external iOS tests, as well as the CocoaPods version used in RNTester (and therefore, the internal CocoaPods offline mirror).
New versions used:
* Xcode 13.0.0
* CocoaPods 1.11.2
See Circle CI Xcode 13.0.0 macOS Container Software manifest: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v6052/index.html
* Xcode 13.0 Build version 13A233
* CocoaPods 1.11.2
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31253170
fbshipit-source-id: c85f3ee12fa708d9e54fef1200f3124810211d2f
Summary:
Since Apple released its own silicon M1, an ARM64, the react-native build is broken or at least not as effective as it should.
This PR stops excluding `arm64` simulator (this is not needed on the M1 neither on Intel devices) and removes the problematic `$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)` from `LIBRARY_SEARCH_PATHS`, since on Xcode 12.5 and 13.0 this folder contains only `i386/x86_64` binaries and will fail compilation.
Instead this PR forces `$(SDKROOT)/usr/lib/swift` while it removes the incorrect directory. Ideally we could just remove `LIBRARY_SEARCH_PATHS` altogether if `$(inherited)` and `$(SDKROOT)/usr/lib/swift` were the only entries, but it would require us a **newer CocoaPods**, since that was fixed with `1.11` (see 6985cbf7de). Since we don't enforce that, lets keep the `$(SDKROOT)/usr/lib/swift` and call it done.
Last but not least, deprecate the `__apply_Xcode_12_5_M1_post_install_workaround()` as it's not needed anymore, at least with recent versions of the dependencies, no patching is required with RCT-Folly, neither we need to force `IPHONEOS_DEPLOYMENT_TARGET=11.0`
## Changelog
[iOS] [Fixed] - Xcode 12.5+ build of iPhone Simulator on Apple M1
[iOS] [Changed] - Do not exclude the arm64 iphonesimulator
[iOS] [Deprecated] - __apply_Xcode_12_5_M1_post_install_workaround()
Pull Request resolved: https://github.com/facebook/react-native/pull/32284
Test Plan:
* Build `packages/rn-tester` on M1 and see it still works properly
* Run `pod install` on x86_64 and arm64 (m1) and see the `project.pbxproj` is not changed
## References:
* Closes https://github.com/facebook/react-native/issues/31480
* The initial fix ac4ddec542
* Upgrading CocoaPods to 1.11 would bring us 6985cbf7de and we could avoid adding `$(SDKROOT)/usr/lib/swift` ourselves
Reviewed By: lunaleaps
Differential Revision: D31248460
Pulled By: fkgozali
fbshipit-source-id: 5a0d69593e889e296a2ba2e7b4387ecbd56fc08d
Summary:
Nightlies will be tagged with the commit they are based off and a timestamp.
> Example: `react-native-0.0.0-084a8b5f0-20210928-054053`
Commitlies now use the proper name on Circle CI for their job: `build_commit_package`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31224640
fbshipit-source-id: d1742a1d475aaf60d7b4c0708e30a5c5b205182d
Summary:
Scheme names may contain whitespace characters is used as path of the
path for various files during build time. This means any path that
includes the scheme name in it needs to be surrounded by quotes.
You can see the generated command below for a project with a scheme
called `Some Scheme`:
node ./node_modules/react-native/cli.js bundle \
--entry-file index.js \
--platform ios \
--dev false \
--reset-cache \
--bundle-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle' \
--assets-dest './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app' \
--sourcemap-output ./ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle.map
`--bundle-output` and `--assets-dest` are properly quoted, but
`--sourcemap-output` is not.
This changes `$EXTRA_ARGS` to an array of strings so that we can
propertly quote `$PACKAGER_SOURCEMAP_FILE` when passing it to the
`--sourcemap-output` argument. When running the bundle command, this
array is unwrapped and all its elements passed as individual arguments.
It also applies the same unwrapping to `$EXTRA_PACKAGER_ARGS` so that
users can also pass an array of options when arguments containing spaces
are needed.
It's important to note that these changes ARE backwards compatible: if
`$EXTRA_PACKAGER_ARGS` is defined as a simple string, instead of an
array of strings, the command won't break, as it will still expand
correctly.
## 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
-->
[iOS] [Fixed] - Source map path for schemes containing whitespaces
Pull Request resolved: https://github.com/facebook/react-native/pull/31587
Test Plan:
With the new change, the generated command becomes:
node ./node_modules/react-native/cli.js bundle \
--entry-file index.js \
--platform ios \
--dev false \
--reset-cache \
--bundle-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle' \
--assets-dest './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app' \
--sourcemap-output './ios/derivedDataBuild/Build/Intermediates.noindex/ArchiveIntermediates/Some Scheme/BuildProductsPath/Release-iphoneos/Some Scheme.app/main.jsbundle.map'
Reviewed By: yungsters
Differential Revision: D30911631
Pulled By: charlesbdudley
fbshipit-source-id: 0c2d98746b365285fe693bcc867a24d3fc649f50
Summary:
About asdf-vm: https://asdf-vm.com/
This PR add [asdf-vm](https://asdf-vm.com/) support to `find-node.sh` for `scripts/react-native-xcode.sh` in `Bundle React Native code and images` build phrase and potentially other scripts using `find-node.sh` to get executable nodejs
## Changelog
[iOS] [Added] - add asdf-vm support in find-node.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/30111
Test Plan: Xcode is able to complete `Bundle React Native code and images` build phrase without errors when node is installed by asdf-vm
Reviewed By: yungsters
Differential Revision: D31064080
Pulled By: charlesbdudley
fbshipit-source-id: aa73620fc39027c58c9cdfbb554cd5698b917850
Summary:
The version of npm available in Circle CI is 6.x, which does not support the `--pack-destination` argument. As a result, `npm pack --pack-destination build` was interpreted as a request to package the 'build' directory for distribution.
Since we need to make sure the output of `npm pack` is consumed by Circle CI's `store_artifacts` directive, we move the commitlies release packing logic to the Circle CI job config itself as to reduce coupling between `publish-npm.js` and the Circle CI config.
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31183635
fbshipit-source-id: f0e0baae4ae31941dbb78dd1fec689f0f3398b52
Summary:
We only need to ensure `react-native-codegen` is a direct dependency of `react-native` in open source releases. Otherwise, we can use the package from source at `packages/react-native-codegen`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31190817
fbshipit-source-id: 527b1c370a35c3efad2448b510172a87c7345ee2
Summary:
Otherwise known as "commitlies," these are per-commit releases that do not get published to npm. They can be downloaded from Circle CI's artifacts pane on the relevant "build_npm_package" job.
If `--dry-run` flag is passed to `publish-npm.js`, it will perform the same steps as a `--nightly` but it will stop short of publishing the nightly to npm. The tarball for the release will be available in the `build/` directory.
Commitlies are implemented by triggering a `--dry-run` publish step on any commit that is not tagged as an open source release (e.g. `/v[0-9]+(\.[0-9]+)*(\-rc(\.[0-9]+)?)?/`).
Changelog:
[Internal]
Reviewed By: sota000
Differential Revision: D31177828
fbshipit-source-id: 7d4f79e1ed15718a177d2cb8fc620d5fb860ccf9
Summary:
There was some hardcoded validation logic to verify package.json and gradle.properties update. Running `pod install` before that failed this validation on release branch, so let's move the pod update a bit later in the flow.
This also restrict the version number change check to the specific files for better reliability
Changelog: [Internal]
Reviewed By: sota000
Differential Revision: D31160139
fbshipit-source-id: d32470d7dfc48c2efab1d2767f3892b33e0b77dd
Summary:
To ensure consistency of RNTester Podfile.lock:
* introduce a script to run `pod install` on the current commit
* have the script check the exact CocoaPods version to use for consistency
* have version bump script run this automatically to keep it up-to-date with the version change
To validate, have this change in `0.66-stable` branch, then try:
```
./scripts/bump-oss-version.js 0.66.0-rc.5
```
This automatically ran `pod install` which produced the Podfile.lock update.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D31132867
fbshipit-source-id: 1c82653ca0cfc5471ed2c5091c09648a7acbab90
Summary:
When running `scripts/react_native_pods.rb`, the `Pods` directory may not be in the current working directory, for example, when calling [`pod install`](https://guides.cocoapods.org/terminal/commands.html#pod_install) with `--project-directory=ios`. Therefore, `sed` fails and, ultimately, the build fails.
References:
* https://rubydoc.info/gems/cocoapods/Pod%2FInstaller:sandbox
* https://rubydoc.info/gems/cocoapods/Pod/Sandbox#root-instance_method
## Changelog
[iOS] [Fixed] - Fix build error after running `pod install` with `--project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32243
Test Plan:
1. `npx react-native init AwesomeProject --version 0.66.0-rc.3 --skip-install`
2. `cd AwesomeProject`
3. `yarn install`
4. `pod install --project-directory=ios`
This command prints “sed: Pods/RCT-Folly/folly/portability/Time.h: No such file or directory” but still exits with 0.
5. `npx react-native run-ios`
The build fails because of “typedef redefinition with different types” as described in https://github.com/facebook/flipper/issues/834.
6. Apply this patch using `(cd node_modules/react-native && curl ec330f756e.patch | patch -p1)`
7. Re-run `pod install --project-directory=ios`
8. Re-run `npx react-native run-ios`
The iOS app should now run successfully.
Reviewed By: sota000
Differential Revision: D31089656
Pulled By: fkgozali
fbshipit-source-id: 431898bed88f68761c7e0e6c79074dc04f43ed23
Summary:
Fix the `find-node.sh` call in `react-native-xcode.sh` script
## Related issue
https://github.com/facebook/react-native/issues/32168
## Changelog
[iOS] [Fixed] - Fix for unable to find `find-node.sh` in `react-native-xcode.sh` script
Pull Request resolved: https://github.com/facebook/react-native/pull/32227
Test Plan: • Run an Xcode build which uses the `scripts/react-native-xcode.sh` in the JS Bundle build phase.
Reviewed By: TheSavior
Differential Revision: D31022043
Pulled By: GijsWeterings
fbshipit-source-id: 10aafd595c3a3a87c22f385ca4f61756f67e9b9d
Summary:
Changelog: [Internal] - Port facebook/react-native/commit/cae063798652fcf394ccf3af4645fd971ed76c19 to main
This was something added to 0.65 branch when they were testing that release.
Comments from Lorenzo:
> When you do the local E2E test script a few times there are some files that get cached even if you try to be careful and wipe everything every time
but in particular during 0.64 when we were trying to investigate an iOS build problem we had inconsistency in repro because of caching because of the package name
so we introduced the extra "timestamp" in the name to avoid any "collisions" with existing caches
Reviewed By: fkgozali
Differential Revision: D30954323
fbshipit-source-id: e0196ee1e0f0c6e05a846d93d72e8c4efe175fb5
Summary:
Just fixing a minor typo
Changelog:
[Internal] - Fixing a minor typo in the verify-android-sdk script
Reviewed By: sshic
Differential Revision: D30933339
fbshipit-source-id: b9191089b67dc05813609702dababc3e36a5e6f8
Summary:
First part of the codegen script cleanup effort. Everything that was done in generate-specs.sh is now part of the CocoaPods recipe (e.g. codegen method in `react_native_pods.rb`).
Now that `generate-specs.sh` has been removed, the codegen may still be invoked manually for test purposes like so:
```
cd react-native
# Generate Schema - do this whenever your JS specs change
node packages/react-native-codegen/lib/cli/combine/combine-js-to-schema-cli.js <output_file_schema_json> <javascript_sources_dir>
# Generate native interfaces for iOS (use schema.json generated by previous step)
node scripts/generate-specs-cli.js ios <output_file_schema_json> <output_dir> <library_name>
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30648067
fbshipit-source-id: 29688e0aac5496886657db82becb05bc8da076c9
Summary:
This reverts https://github.com/facebook/react-native/issues/31128 - For the reasons stated in the thread. Files should have the correct endings in the repo (i.e. Windows .bat CRLF). There is no reason to perform additional conversion with attributes and/or an editorconfig. It was originally fixed in https://github.com/facebook/react-native/issues/29792 in August 2020.
⚠️ **EDIT 2021-08-31**
Commits 85249cafe8 and 13107fa3d0 accidentally converted the gradlew.bat files to LF again, resulting in modified files to appear in the working directory:
```
$ git status -s
M gradlew.bat
M packages/react-native-codegen/android/gradlew.bat
M template/android/gradlew.bat
```
The reasons why this is happening are explained in detail in the two PRs linked above.
I've added an additional (new) commit to the PR head branch to fix the line endings in all three `gradlew.bat` files of the repo and rebased it. It should be ready for merge.
CC cortinico
EDIT 2021-09-02
The additional commit was removed again, but the original one remains.
To test the scenario locally run the following commands on a clean `main` branch (currently 455433f481):
```
$ rm gradlew.bat
$ git status -s
D gradlew.bat # Git shows the file as (D)eleted, as expected
$ git checkout gradlew.bat # This should restore the file
$ git status -s
M gradlew.bat # The file still shows up, now as (M)odified with all line endings changed
```
The modified file will remain in the working directory until they are committed, or a different branch is _force_ checked out. `gradlew.bat` files are generated automatically by Gradle (with the correct line endings in the first place). There is no need to special case them and perform line ending conversion using Git and/or editorconfig.
## Changelog
[General] [Fixed] - Line endings in Windows files, Git/EditorConfig related conversions
Pull Request resolved: https://github.com/facebook/react-native/pull/31398
Test Plan: Verify files are stored correctly in the repository (e.g. using the `file` command).
Reviewed By: yungsters
Differential Revision: D30839864
Pulled By: cortinico
fbshipit-source-id: dfc53e8c5d9276d2f9bfd4d4a4e6b44c3143a164
Summary:
Fixes the issue explained in https://github.com/facebook/react-native/issues/28446
It basically disabled the gflags include before configure can detect the header on the users system.
## Changelog
[iOS] [Fixed] - Fixed inability to build apps when gflags is installed
Pull Request resolved: https://github.com/facebook/react-native/pull/28451
Test Plan: Tested by installing gflags `brew install gflags` and verifying that apps build after.
Reviewed By: javache
Differential Revision: D30345352
Pulled By: sota000
fbshipit-source-id: 04c98d7ddebe6708057407c4b4bf3701434822a3
Summary:
Use the same technique as other flipper transitive deps to make sure it is excluded from release builds.
## Changelog
[iOS][Fixed] - Exclude OpenSSL-Universal flipper dependency from release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31938
Test Plan: Tested in an app that it still builds and works.
Reviewed By: mweststrate
Differential Revision: D30674216
Pulled By: yungsters
fbshipit-source-id: f2ab5154c80036e6df90d1a98882cc4b85734485
Summary:
Changelog: [Internal[Fixed] - Revert, yarn workspaces only used in private packages. Copy dependencies over from repo-config instead
Original commit changeset: 1dd2adc6a036
Reviewed By: fkgozali
Differential Revision: D30599065
fbshipit-source-id: 0efffaaf38bc23bac339e6e1d917736243e1750e
Summary:
Context: there are multiple issues currently exposed by Xcode 12.5 and/or M1 machine + Flipper. To unblock the new 0.66 release, let's add this workaround in the official react_native_pods.rb recipe and make RNTester and new app Podfile's call it directly.
Changelog: [iOS][Fixed] Added workaround for Xcode 12.5 / M1 machines build issues
Reviewed By: lunaleaps
Differential Revision: D30691291
fbshipit-source-id: 8b24cc60da3d620dbc90f95c77f2345e18c28212
Summary:
The original $ENTRY_FILE check was added in https://github.com/facebook/react-native/pull/29012 to help catch misconfiguration for the entry JS file. That turned out breaking some RNTester builds/tests, so https://github.com/facebook/react-native/pull/29263 was added to accommodate the fact that RNTester .xcodeproj file has its own directory hierarchy.
The 2nd PR had multiple issues:
* It is incorrect to assume that the $ENTRY_FILE always exists in the parent dir of the .xcodeproj location. This caused an issue in RC 0.66: https://github.com/react-native-community/releases/issues/249#issue-983474535
* RNTester has since moved to packages/rn-tester/ (from RNTester/), hence breaking that assumption
It turns out RNTester .xcodeproj has incorrectly misconfigured this JS bundling step (not sure since when). The original script invocation passed in the correct path for `RNTesterApp.ios.js`, but as an arg to the `react-native-xcode.sh` instead of by setting `ENTRY_FILE` env var.
So this diff does 2 things:
* Undid https://github.com/facebook/react-native/pull/29263
* Fix RNTester JS bundling invocation to set the ENTRY_FILE correctly
{F659123377}
Changelog: [iOS][Fixed] Unbreak $ENTRY_FILE handling for JS bundling
Reviewed By: lunaleaps
Differential Revision: D30690900
fbshipit-source-id: 7c5802b3eac56c0456edcd4b7478bfa4af48fc27
Summary:
The codegen script now takes parameters for any necessary configuration. Now, there are three *required* parameters: JS_SRCS_DIR, LIBRARY_NAME, and OUTPUT_DIR.
By default, all modules and components output will be copied to the OUTPUT_DIR under a single LIBRARY_NAME.
If a fourth argument is provided, this COMPONENT_LIBRARY_NAME will be used for the component library name.
If a fifth argument is provided, this COMPONENT_OUTPUT_DIR will be used as the output directory for the component library.
These last two arguments are used to build the core FBReactNativeSpec modules and rncore components libraries. Eventually, all module and component output will be part of a single library, but for the time being we need to keep these apart for the core modules and components.
The script will output usage instructions if no argument is provided:
```
./scripts/generate-specs.sh
NAME
./scripts/generate-specs.sh -- generate specs
SYNOPSIS
./scripts/generate-specs.sh javascript_sources_directory specs_library_name output_directory
./scripts/generate-specs.sh javascript_sources_directory specs_library_name output_directory component_library_name [component_output_directory]
DESCRIPTION
In the first synopsis form, this script collects native module and native component JavaScript spec definitions in javascript_sources_directory, then uses react-native-codegen to generate the native interface code into a library named specs_library_name, which is copied to the destination output_directory.
In the second synopsis form, the component_library_name will be used as the name of the component native interface code library. If provided, the component output will be copied to the component_output_directory, otherwise it will be copied to the output_directory.
```
With these changes, `codegen.js` became redundant and has been removed.
Changelog:
[Internal] - Codegen script interface changes.
Reviewed By: fkgozali
Differential Revision: D30626294
fbshipit-source-id: 475c29242497db5f93213aa64ca9b7c480140d55
Summary: Changelog: [Internal][Fixed] - Keep repo-config as a workspace for bumping oss release version. Fixes CI jobs not having tooling dependencies
Reviewed By: yungsters
Differential Revision: D30595543
fbshipit-source-id: 1dd2adc6a0363202efb5314b7e8eb44618b50327
Summary:
Currently, the build breaks if we move `react-native-codegen` from the template's dependencies to root. This is due to `scripts/generate-specs-cli.js` using the one installed under `node_modules` instead of the local one.
## 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
-->
[Internal] [Fixed] - `scripts/generate-specs-cli.js` should prefer the local `react-native-codegen` package
Pull Request resolved: https://github.com/facebook/react-native/pull/32096
Test Plan:
1. Make the following changes
```diff
diff --git a/package.json b/package.json
index 847c726a69b..78da8232988 100644
--- a/package.json
+++ b/package.json
@@ -107,6 +107,7 @@
"promise": "^8.0.3",
"prop-types": "^15.7.2",
"react-devtools-core": "^4.13.0",
+ "react-native-codegen": "^0.0.7",
"react-refresh": "^0.4.0",
"regenerator-runtime": "^0.13.2",
"scheduler": "^0.20.2",
diff --git a/template/package.json b/template/package.json
index 715614112ac..5e0762b1b25 100644
--- a/template/package.json
+++ b/template/package.json
@@ -21,7 +21,6 @@
"eslint": "7.14.0",
"jest": "^26.6.3",
"metro-react-native-babel-preset": "^0.66.2",
- "react-native-codegen": "^0.0.7",
"react-test-renderer": "17.0.2"
},
"jest": {
```
2. Run `scripts/test-manual-e2e.sh`
## Expected Behavior
Task `:ReactAndroid:buildReactNdkLib` succeeds.
## Actual Behavior
```
> Task :ReactAndroid:buildReactNdkLib FAILED
make: Entering directory '~/Source/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
make: Leaving directory '~/Source/react-native/ReactAndroid/src/main/jni/react/jni'
~/Library/Android/sdk/ndk/21.4.7075529/build/core/build-binary.mk:651: Android NDK: Module react_codegen_rncore depends on undefined modules: react_render_components_view
~/Library/Android/sdk/ndk/21.4.7075529/build/core/build-binary.mk:664: *** Android NDK: Note that old versions of ndk-build silently ignored this error case. If your project worked on those versions, the missing libraries were not needed and you can remove those dependencies from the module to fix your build. Alternatively, set APP_ALLOW_MISSING_DEPS=true to allow missing dependencies. . Stop.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':ReactAndroid:buildReactNdkLib'.
> Process 'command '~/Library/Android/sdk/ndk/21.4.7075529/ndk-build'' finished with non-zero exit value 2
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.9/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 19s
20 actionable tasks: 20 executed
Couldn't generate artifacts
```
Reviewed By: ShikaSD
Differential Revision: D30581194
Pulled By: hramos
fbshipit-source-id: 3f7a707b33377042502e50887856ff5641fdd52c
Summary:
We want to resolve `NODE_BINARY` **after** `find-node.sh` runs and sets up any node version manager that we need to setup, otherwise `NODE_BINARY` is always undefined.
## Changelog
[Internal] [Fixed] - Resolve NODE_BINARY after finding the right path to node
Pull Request resolved: https://github.com/facebook/react-native/pull/32029
Reviewed By: TheSavior
Differential Revision: D30401213
Pulled By: yungsters
fbshipit-source-id: 386ffeff15b5f371a452488ed078d3adebe0f211
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32042
This diff moves react_native_log out of utils to make it easier/possible to import from modules.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30411247
fbshipit-source-id: 5482761b259600df051a88c6eff1834c882e7230
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:
Includes fix included in a Flipper Pod for incorrect timestamps in the Network viewer with iOS apps
1cf7456133
## 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][changed] - Update Flipper to 0.99.0
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/31896
Reviewed By: fkgozali
Differential Revision: D29881218
Pulled By: mdvacca
fbshipit-source-id: a206faa3d7b969a708d286884cff83bed5453d22
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Updates documentation in React Native to reference `main` (or `HEAD` for URLs) instead of `master`.
Part of https://github.com/facebook/react-native/issues/31788.
Changelog:
[General][Changed] - Update documentation reference from `master` to `main` or `HEAD`.
Reviewed By: JoshuaGross
Differential Revision: D29717128
fbshipit-source-id: 0b0babd8407c6fd3d0e5431f6eaf976059731d6f
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:
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:
A recent commit 941bc0ec19 (diff-0eeea47fa4bace26fa6c492a03fa0ea3923a2d8d54b7894f7760cb9131ab65eb) on Hermes macOS brings a regression for Mac Catalyst target.
Once hardcoded cli bundle platform `ios` can now be either `ios` or `macos`. However, Mac Catalyst is identified as `macos` rather than `ios`.
This PR should fix it and close https://github.com/facebook/react-native/issues/31061.
## Changelog
[iOS] [Fixed] - Fix cli bundle platform for Mac Catalyst in `react-native-xcode.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/31062
Test Plan:
1. Build fails on a new RN 0.64-rc.3 project.
2. Apply the fix.
3. Build passes.
Reviewed By: TheSavior
Differential Revision: D29038793
Pulled By: appden
fbshipit-source-id: 29761f887ec7a9cc26f088953c3888c6d19bed71
Summary:
Changes React Native CI (both Sandcastle and Circle CI) to use `OS=latest` instead of a hardcoded version number.
This reduces the number of hardcoded configurations needed to be updated for new Xcode versions by one.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D29013193
fbshipit-source-id: 3c081de1b74a130867b2a599d3e7333846c96cf7
Summary:
Adds homebrew on m1 to path before evaluating `command -v brew` to support nvm on m1 via homebrew.
## Changelog
[General] [Changed] - Find node on m1 via homebrew node managers
Pull Request resolved: https://github.com/facebook/react-native/pull/31678
Test Plan:
On M1, use nvm via homebrew. Create a RN project and it'll fail to build iOS app. Apply the patch, and build will succeed.
cc: dulmandakh as discussed in https://github.com/facebook/react-native/pull/31622
Reviewed By: ShikaSD
Differential Revision: D28967386
Pulled By: PeteTheHeat
fbshipit-source-id: 3d4a41dd3cc25fbf77778b16468a236b141d1259
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: https://github.com/facebook/fresco/issues/2603
This primarily bumps to the latest pods we have everywhere, which solves several build issues, like reported in https://github.com/facebook/react-native/issues/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: https://github.com/facebook/react-native/pull/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
Reviewed By: fkgozali
Differential Revision: D28623601
Pulled By: mweststrate
fbshipit-source-id: 22130d07821569851956453c4ee6a594b6b83928
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)
## 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] [UPDATE] - updated react-native-community/cli to v6 (hence updating metro to 0.66)
Pull Request resolved: https://github.com/facebook/react-native/pull/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:
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 d1ab03235c/scripts/react-native-xcode.sh (L106)
Fixes https://github.com/facebook/react-native/issues/31621https://github.com/facebook/react-native/issues/31592
## Changelog
[General] [Changed] - find-node.sh supports Homebrew on M1
Pull Request resolved: https://github.com/facebook/react-native/pull/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:
Updates Gradle script to include new version of folly (synced to iOS update)
Adds fmt and libevent as well as some boost ASM sources to enable compilation of folly futures.
Changelog:
[Android] Updated folly to 2021.04.26
Reviewed By: fkgozali
Differential Revision: D28124377
fbshipit-source-id: d44c5a1ded5ee7ad514a9df14ea2ba326d4aa0e3
Summary:
- Fixed iOS codegen script incorrectly splitting root project paths that contain spaces
https://github.com/react-native-community/releases/issues/214#issuecomment-793089063
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: https://github.com/facebook/react-native/pull/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
Héctor Ramos
Franco Meloni
Riccardo Cipolleschi
Nicola Corti
Mike Hardy
fortmarek
Luna Wei
Kudo Chien
matinzd
Danilo Bürger
Andrei Shikov
Oleg Kot
Scott Kyle
Dmitry Rykun
Samuel Susla
Ian Childs
Gabriel Donadel Dall'Agnol
Lorenzo Sciandra
Max Thirouin
Tommy Nguyen
Sota Ogo
Andres Suarez
Janic Duplessis
Simon Farshid
Ian Grayson
Neil Dhar
enniel
Jesse Katsumata
Liam Jones
Moti Zilberman
Tim Yung
rayzr522
Joel Arvidsson
Gustavo Sverzut Barbieri
Michael Neeley
Anderson Mesquita
PastLeo
Kevin Gozali
Jakob Krigovsky
Gareth Knowles
Frieder Bluemle
Kai Dederichs
Xuan Huang
pera
Matthew Gray
Stefan Wrobel
Michel Weststrate
Rui Ying
Danilo Bürger
Peter Argany
Michel Weststrate
Dulmandakh
Thibault Malbranche
Ramanpreet Nara
Craig Martin
