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
Summary:
Currently, various CircleCI jobs intermittently fail when trying to fetch dependencies via Maven.
This adds a few retries before failing the CircleCI job to reduce noise from intermittent network fetch failures.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D28153008
fbshipit-source-id: ac944882ff0495f568973a709d6d61ef7b51b318
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
We have had problems with `.gitattributes`, `.bat` and `.pbxproj` (Xcode) files for a while. The two main concerns were:
- Xcode project files not diffing correctly.
- Windows files having messed up line endings.
This PR fixes both issues, hopefully forever.
After seeing the diffs from v0.63 -> v0.64 and the changes in https://github.com/facebook/react-native/pull/29792, I, again, felt that this is going to cause problems, so I looked into both issues.
I started with `git check-attr -a Artsy.xcodeproj/project.pbxproj` after removing the `.gitattributes` file that contained `*.pbxproj -text` and there are no "guessed" attributes that would break things, and diffing and checking in worked well with the current git version. I agree this is not needed, so I left it out.
I looked into what it was doing before, and it was telling git (for the xcode project file) to "unset text", which means (according to https://git-scm.com/docs/gitattributes#_text) that it should not try to do any line ending changes when checking in that file. At some point git must have done this, and that's why it was needed, but no more, so it's safe and good to get rid of this, as it helps with nothing anymore.
Now for the bat files. We don't need any extra instructions for `gradle` and `*.sh` files as they are guessed correctly, so these are also safe to keep removed (https://github.com/facebook/react-native/pull/29792/files#diff-618cd5b83d62060ba3d027e314a21ceaf75d36067ff820db126642944145393eL5).
But we do need the `*.bat` instruction. I noticed that when working on macOS there were two problems that made things funky.
- One, is that the editor (usually vscode but not the important) would convert line endings to lf when editing a bat file.
- Two, is that git thought the files are lf line endings.
To fix the first one, I added a rule in `.editorconfig` (that's whats important, when any editor just supports editorconfig, but all my editors do). I can't believe how we missed that for sooooo long {emoji:1f605}!
To fix the second, I added the `.gitattributes` instruction **and** `renormalize`d the files (https://git-scm.com/docs/git-add#Documentation/git-add.txt---renormalize and https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings). I think the problem all along was that even though the files had crlf, git still thought they were using lf.
After the editorconfig change and the renormalization, everything behaves correctly and as expected. Changing bat files on macOS and Windows is fine now, producing only the smallest change needed, no random line ending diffs. Also here is a screenshot of one of the files actually crlf. It's these tiny things at the end of each line {emoji:1f453}.
<img width="612" alt="Screenshot 2021-03-10 at 12 20 28" src="https://user-images.githubusercontent.com/100233/110630943-ef536280-819d-11eb-9212-dbd70f038a44.png">
I have tested this on macOS and Windows, doing changes in both bat and xcode files, and verified that diffing and checking in files works well.
## 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] - Added an `.editorconfig` file to help with default line endings for Windows files.
[Internal] [Fixed] - Added a rule in `.editorconfig` and `.gitattributes` to help with default line endings for Windows files.
Pull Request resolved: https://github.com/facebook/react-native/pull/31128
Test Plan: Feel free to go on a macOS or Windows machine (or both) and, using any editor that supports editorconfig, do any change in a `.bat` file. Then look at your git diff in terminal or gui or whatever you use, and then look at the sky and smile. It's fixed. The diff is just your change. Everything is as it should {emoji:1f49c}.
Reviewed By: nadiia
Differential Revision: D27914636
Pulled By: hramos
fbshipit-source-id: fc4e53a4fa42cb13e29686669e8de1679c2242e7
Summary:
The `SPEC CHECKSUM` for `FBReactNativeSpec` in `packages/rn-tester/Podfile.lock` and in standalone apps's `ios/Podfile.lock` varies between development machines. This is caused by local paths in the output of `pod ipc spec FBReactNativeSpec.podspec`, such as `output_files` and `prepare_command`. This causes the Podfile.lock to constantly change when pod install is run on different developers' machines.
The codegen script and CocoaPods configuration have been updated to use relative paths.
Closes https://github.com/facebook/react-native/issues/31193
Changelog: [Internal] [Codegen] Avoid encoding local path in Podfile.lock
Reviewed By: fkgozali
Differential Revision: D27754337
fbshipit-source-id: 2f5607d4e1ce21489f28f394cb852c36cace6798
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
This fix is ported from 0.64-stable. It moves the Node resolution script from react-native-xcode.sh to find-node.sh for re-use in the codegen.
Changelog: [Codegen][Internal]
Reviewed By: fkgozali
Differential Revision: D27437216
fbshipit-source-id: ecb8a7a30411a709c095a0a34115b6dc48b99f1e
Summary:
allow-large-files
RN Tester is using an old version of Flipper. This will help testing regressions in the latest version (which is installed when starting a new project). This also fixes an issue where libevent is incompatible between the one in flipper and when using hermes on iOS. To fix it I changed to use the version published on cocoapods instead of using a local podspec (see https://github.com/facebook/flipper/issues/1916).
## Changelog
[General] [Changed] - Update flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/31010
Test Plan:
- Tested that RN tester builds and flipper works with hermes enabled / disabled and fabric on iOS
- Tested that RN tester builds and flipper works on Android
Reviewed By: fkgozali
Differential Revision: D26592317
Pulled By: PeteTheHeat
fbshipit-source-id: 2cd278c7a51b1859dab0465846b061221f07d3f6
Summary:
Currently, Codegen bash wrapper (`generate-specs.sh`) for Xcode invokes JS-based Codegen tooling via `yarn --silent node <...>`. This breaks both:
- when Yarn is not installed (if NPM is used), for obvious reasons
- when Yarn v2 ("Berry") is active
This PR changes the way `generate-specs.sh` locates `node` executable to the following algorithm:
- use the path provided in the `NODE_BINARY` env var
- if `NODE_BINARY` env var is not defined, find `node` with `command -v node`
## Changelog
[iOS] [Fixed] - Fix Codegen silently failing when Yarn is not installed, or when Yarn v2 is active.
Pull Request resolved: https://github.com/facebook/react-native/pull/30781
Test Plan:
### Case 1 (no Yarn installed)
1. Ensure `yarn` is not present in PATH
2. Run Xcode build
3. Check that Codegen artifacts are produced
### Case 2 (Yarn v2 is used)
1. Ensure `yarn` is running in the v2 ("Berry") mode
2. Run Xcode build
3. Check that Codegen artifacts are produced
Reviewed By: fkgozali
Differential Revision: D26187081
Pulled By: hramos
fbshipit-source-id: 77d3089f523b8c976d8223b77ff9553cb6cf68a5
Summary:
This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS.
1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly.
2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file.
3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups.
4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not.
## Changelog
[iOS] [Fixed] - Make codegen more reliable on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/30792
Test Plan:
Tested various project states to make sure the build always succeeds in RN tester:
- Simulate fresh clone, remove all ignored files, install pods, build
- Build, delete FBReactNativeSpec generated files, build again
- Build, build again, make sure FBReactNativeSpec is cached and not rebuilt
- Make the script fail and check that xcode shows the script error logs properly
Note: Did not test fabric
Reviewed By: fkgozali
Differential Revision: D26104213
Pulled By: hramos
fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
Summary:
Today I created a project with RN 0.63 and it failed to **pod install**, and after some investigation I found following error. It's caused by Xcode 12 because it dropped support for 32 bit architectures, but following script sets architecture to armv7 which is 32bit.
This will change architecture to arm64, 64 bit.
```
configure:3727: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.1.sdk conftest.c >&5
clang: error: invalid iOS deployment version 'IPHONEOS_DEPLOYMENT_TARGET=12.0', iOS 10 is the maximum deployment target for 32-bit targets [-Winvalid-ios-deployment-target]
configure:3731: $? = 1
```
## 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] - fix glog pod install with Xcode 12
Pull Request resolved: https://github.com/facebook/react-native/pull/30372
Test Plan: Create a new project using react-native init, and it'll fail to do pod install. When this change applied, it'll do it successfully.
Reviewed By: fkgozali
Differential Revision: D25957237
Pulled By: PeteTheHeat
fbshipit-source-id: 4ecfaee29da4171fb190352927ec47dbb73fbaa0
Summary:
In a4d8632890, I removed javadoc.jar, and sources.jar generation, but forgot to change artifact validation for NPM publish. This PR removes javadoc.jar and sources.jar from validation.
## Changelog
[Internal] [Changed] - remove javadoc.jar, sources.jar from NPM package validation
Pull Request resolved: https://github.com/facebook/react-native/pull/30686
Test Plan: publish_npm_package CI job must succeed.
Reviewed By: mdvacca
Differential Revision: D25775320
Pulled By: fkgozali
fbshipit-source-id: b2cff66986818c5216754dcf14d9fcd756d14231
Summary:
The codegen helper script, `generate-specs.sh`, is being used to generate code for the FBReactNativeSpec and React-Fabric/rncore pods. The script now supports overriding several defaults by setting the following environment variables:
- SRCS_DIR: Path to JavaScript sources, defaults to $RN_DIR/Libraries/
- LIBRARY_NAME: Defaults to FBReactNativeSpec
- MODULES_OUTPUT_DIR: Defaults to Libraries/$LIBRARY_NAME/$LIBRARY_NAME
- COMPONENTS_LIBRARY_NAME: Defaults to rncore
- COMPONENTS_OUTPUT_DIR: Defaults to ReactCommon/react/renderer/components/$COMPONENTS_LIBRARY_NAME
The CocoaPods codegen integration has been updated to take advantage of these.
**Example CocoaPods usage:**
```
# packages/rn-tester/NativeModuleExample/RNTesterSpecs.podspec
Pod::Spec.new do |s|
s.name = "RNTesterSpec"
# ...
use_react_native_codegen!(s, { :srcs_dir => __dir__, :modules_output_dir => __dir__ })
end
```
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25738466
fbshipit-source-id: c68f5a3cd0996283a7af287e992e2f973024f44c
Summary:
Consolidate CocoaPods codegen scripts under a single `use_react_native_codegen!` method in `react_native_pods.rb`.
This is the first step towards making the codegen scripts library-agnostic. There are still a handful of hardcoded assumptions in place (e.g. the output directory structure, the use of a separate directory for components), but with some work one would be able to add codegen support to arbitrary CocoaPods podspecs.
The codegen script no longer takes a CODEGEN_PATH argument, and will instead attempt to use the local react-native-codegen package if available, and fallback to using the node_modules/react-native-codegen package if not.
## Usage
The `use_react_native_codegen!` method has two arguments:
- `spec`, a pod [Specification](https://www.rubydoc.info/github/CocoaPods/Core/Pod/Specification) object.
- `options`, an optional object. Supported keys:
- `:srcs_dir`, the path to your JavaScript sources. Your native module or component specs should be located somewhere in this directory.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25728053
fbshipit-source-id: feec587b656d5b220598ce6196ea6bb34a9580a9
Summary:
Original PR contents:
This pull request updates the Podspecs and associated build scripts, and some source files so they build on OSS. RNTester now compiles with `fabric_enabled` again.
The following changes have been made:
* Various spots that were pointing to the old `ReactCommon/fabric` location have now been updated to `ReactCommon/react/renderer`
* Files that were attempting to use internal FB header `FBRCTFabricComponentsPlugins.h` were changed to use `RCTFabricComponentsPlugins.h`
* `RCTFabricComponentsPlugins` in OSS was updated to include the `Image` fabric component (thanks tsapeta)
* Replaced old `generate-rncore.sh` build script with new `generate-rncore.js` script which does not require `flow-node` and uses the `react-native-codegen` API directly, so there is no longer any need for an interim `schema-rncore.json` file.
* Updated Yoga podspec which wasn't fully synced with changes from the main Yoga repo
* Updated Fabric podspec with additional needed subspecs
Additions to PR by hramos:
* Replaced use of generate-rncore scripts with the original generate-native-modules-specs.sh script, which is now generate-specs.sh and supports both codegen for Native Modules and Components now (TurboModules/Fabric).
* Codegen now runs at build time as part of the Xcode build pipeline instead of as part of `pod install`. The build script is injected by the FBReactNativeSpec pod, as the pod is part of both Fabric and non-Fabric builds.
## Changelog
[General] [Fixed] - RNTester compiles with `fabric_enabled` again
Pull Request resolved: https://github.com/facebook/react-native/pull/29810
Test Plan:
RNTester now compiles and runs in the simulator again when `fabric_enabled` is set to `true`.
```
cd xplat/js/react-native-github/packages/rn-tester
USE_FABRIC=1 pod install
open RNTesterPods.xcworkspace
# Build and run
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
This commit makes both `:ReactAndroid` and `:rn-tester:android:app` always compile in Fabric codegen outputs. However, one may still enable/disable Fabric at runtime by setting `USE_FABRIC` env var (set to 1 or 0, default is 0).
Note that we can't register custom components specific to the app, yet, so only the components in react-native github repo is covered by this commit.
RNTester doesn't enable Fabric by default yet due to known UI bugs that haven't been addressed yet.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674311
fbshipit-source-id: 8db660c959319250ebc683c84076677cf6489e94
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
When building React Native application in Release mode for an iPhone Simulator _and_ targeting `armv7`, Xcode will build all architectures (due to `ONLY_ACTIVE_ARCH` set to `false`, unlike in Debug mode). As a result, Xcode will try building for `i386` (32-bit iPhone Simulator), which fails as we don’t build Hermes binaries for `i386`.
Fix is to disable `i386`, since it is not supported by `Hermes` and certain `Folly` features.
## Changelog
[IOS] [BREAKING] - `i386` architecture will be automatically disabled when Hermes is being used. This might be potentially breaking for your workflow if you target `armv7` devices, as you will no longer be able to test on the simulator.
[IOS] [FEATURE] - Replace `flipper_post_install` with `react_native_post_install` hook. Will automatically detect if Flipper is enabled.
Pull Request resolved: https://github.com/facebook/react-native/pull/30592
Test Plan: Run React Native application with Hermes enabled (or Flipper) in Release mode and it should work just fine.
Reviewed By: appden
Differential Revision: D25564738
Pulled By: TheSavior
fbshipit-source-id: e786ab73fb0a77de5869cf9e5999726c7d29f1d4
Summary:
Fixes https://github.com/facebook/react-native/issues/29984
Right now, running a React Native application with Xcode 12 in Release mode on an iPhone Simulator will fail with something like below:
> [some file path], building for iOS Simulator, but linking in object file built for iOS, file '[some file path]' for architecture arm64
The best explanation of this issue has been provided by alloy in https://github.com/facebook/react-native/issues/29984:
> This issue has started coming up with Xcode 12 and support for the new ARM based Macs, as `arm64` now no longer can be assumed to _only_ be for iOS devices. This means Xcode 12 will now also build for `arm64` simulator SDKs and it has become ambiguous if an arch slice in a prebuilt binary is meant for a simulator or device.
>
> In any case, for now this means that you can configure your Xcode project to exclude `arm64` when building for any iOS simulator SDK.
This PR implements aforementioned workaround.
## Changelog
[FIX] [IOS] - Fix running React Native project with Xcode 12 in Release on iPhone Simulator
Pull Request resolved: https://github.com/facebook/react-native/pull/30543
Test Plan: Switch your scheme to Release and run the app on simulator. Will complete w/o issues.
Reviewed By: appden
Differential Revision: D25537295
Pulled By: TheSavior
fbshipit-source-id: 2dc05cb80e59f1d95d2a84ab55ed6a5b5446411c
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
Hermes being a subspec of ReactCore causes some build issues when RN is included in 2 different targets. It also causes it to include a lot of additional dependencies that it doesn't need. This moves it to a separate podspec loosely based on other specs in ReactCommon.
## Changelog
[iOS] [Fixed] - Move hermes to a separate podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/30478
Test Plan: Test that it builds and run properly in an app
Reviewed By: fkgozali
Differential Revision: D25308237
Pulled By: hramos
fbshipit-source-id: b4cc44ea2b1b854831e881dbbf9a2f30f6704001
Summary:
The wrong value for the path to react-native-codegen was being used. The issue was introduced during the refactoring of this script for use in FBReactNativeSpec.podspec.
Changelog: [Internal]
Motivation:
Reviewed By: fkgozali
Differential Revision: D25290355
fbshipit-source-id: 5a46c680e7ea41157b03cf54a640a8816fb682b3
Summary:
Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod.
This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed.
The codegen will thus be invoked in these situations:
**RNTester:**
* When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed.
**OSS React Native apps:**
* When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`.
Pull Request resolved: https://github.com/facebook/react-native/pull/30449
Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod
Reviewed By: fkgozali
Differential Revision: D25138896
fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary:
Minification is not needed for hermes as it does all required optimisations on the bytecode. This is what facebook does internally for hermes bundles and I also validated by comparing the bytecode bundle size on a minified and non-minified bundle.
## Changelog
[General] [Changed] - Don't minify JS bundle by default when using hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/30496
Test Plan: Verified that the JS bundled generated on Android and iOS when using hermes is not minified by checking the generated JS file manually.
Reviewed By: rickhanlonii
Differential Revision: D25235195
Pulled By: cpojer
fbshipit-source-id: ad2131aab4dfd17ab53b6a5720ed0e2f1b09cca4
Summary:
Use pre-built react-native-codegen library from npm in the iOS app template.
Built react-native-codegen from source when used with RNTester.
Published react-native-codegen@0.0.6.
Changelog:
[iOS][Added] - Use react-native-codegen in iOS app template
[Internal] - Bump react-native-codegen: 0.0.6
Reviewed By: fkgozali
Differential Revision: D25128036
fbshipit-source-id: f294c23b9b911aae6f404edc01b62426fb578477
Summary:
Add the `react-native-codegen` source to the `react-native` npm package.
Instead of using `react-native-codegen` from npm, the iOS app template will now build the package from source. Doing so removes the need to carefully time `react-native-codegen` npm releases to oss `react-native` releases, as the codegen and the oss release will be cut at the same time.
Changelog: [Internal] - Removed react-native-codegen dependency from iOS app template
Reviewed By: TheSavior
Differential Revision: D24904655
fbshipit-source-id: a07932bc748e2afb9359de584181bcb9dd0810ea
Summary:
This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet.
Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0)
Fixes https://github.com/facebook/react-native/issues/28810 (as above)
Checklist:
- [x] Adjust release scripts to create Hermes bytecode bundle
- [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project)
- [x] Test on a new React Native application in both Debug and Release (Device)
- [x] Test on an RNTester application in both Debug and Release (Device)
- [x] Add missing `i386` to Hermes framework and enable Bitcode
- [x] Inspect CI failures for possible regressions
- [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810
- [x] Release new Hermes and test against it that everything works
## Changelog
[IOS] [FEATURE] - Enable Hermes on iOS
[INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues
[INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI
[INTERNAL] - Fix building RNTester in Release mode
[INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!`
[INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI
[INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway
Pull Request resolved: https://github.com/facebook/react-native/pull/29914
Test Plan:
Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now.
Preview: (note "Engine: Hermes")
<img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png">
Reviewed By: hramos
Differential Revision: D24684845
Pulled By: cpojer
fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
Summary:
Update engines to node >= 12
## 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 node engine to version 12
Pull Request resolved: https://github.com/facebook/react-native/pull/30252
Reviewed By: yungsters
Differential Revision: D24558093
Pulled By: fkgozali
fbshipit-source-id: 7a10bb935f89ba3374b0909161db9974e1fc477a
Summary:
Since changes to support hermes on iOS the js bundled is moved away from the location where it is generated when calling metro. This causes issues with the RN sentry integration since it relies on intercepting this path to find the bundle file after running react-native-xcode.sh. Seems kind of like a hacky way to get the bundle location, but let's avoid breaking it.
https://github.com/getsentry/sentry-cli/blob/master/src/commands/react_native_xcode.rs
## Changelog
[iOS] [Fixed] - Make sure js bundle still exists at bundle-output path
Pull Request resolved: https://github.com/facebook/react-native/pull/30149
Test Plan:
Checked that the bundle file exists both at bundle-output path and in the .app.
Checked that the sentry release script works.
Reviewed By: cpojer
Differential Revision: D24480115
Pulled By: appden
fbshipit-source-id: c01c80d47ed54319f97063ec635c021552a95c22
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
Move FBReactNativeSpec codegen invocation to shared `react_native_pods.rb` script and trigger codegen to run as part of `pod install` in both RNTester as well as React Native for iOS projects.
These files need to be generated before CocoaPods generates the Pods project, so the codegen is invoked as part of a `pre_install` hook during `pod install`.
The codegen hook can now take optional paths to allow it to run within different contexts (as part of a `react-native` repo checkout with access to the codegen source, or as part of a React Native iOS project that depends on the `react-native-codegen` npm package).
## Motivation
The FBReactNativeSpec ObjC++ source files (FBReactNativeSpec.h and FBReactNativeSpec-generated.mm) can be generated on demand from the native module specs in `Libraries/` using `react-native-codegen`. They can therefore be removed from the repository, but before we do so, we must ensure they get generated when a React Native iOS workspace is created or updated.
Invoking the codegen as part of the `pod install` step that creates a React Native iOS Xcode workspace ensures the specs are available in the following scenarios:
* Whenever a new React Native iOS project is created. The `react-native init` command invokes `pod install`.
* Whenever a React Native iOS project is upgraded. The `react-native upgrade` command invokes `pod install` as well.
* For contributors to the open source project running the RNTester application, the codegen will be invoked when the RNTester workspace is generated by CocoaPods using `pod install` in `packages/rn-tester`.
In any other case, the codegen can still be invoked directly via `scripts/generate-native-modules-specs.sh`.
> **Note:**
> The codegen will only process native modules in React Native's own Libraries directory.
Changelog:
[iOS][Changed] - Generate FBReactNativeSpec ObjC++ source files using CocoaPods.
Reviewed By: fkgozali
Differential Revision: D24348111
fbshipit-source-id: d62ae5c6f8ce6358bf96a2801c3cdb3d94dd868d
Summary:
A `cat` to file was removed accidentally, preventing the configuration script from executing successfully as part of a `pod install`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24024824
fbshipit-source-id: 94af0c6e663320bfac04ee8f6fb37bd4bdc379a4
Summary:
These native modules are now filtered downstream in `combine-js-to-schema-cli.js`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24003572
fbshipit-source-id: d858dbf4a4b6d522ed528f9c2262f37243317160
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## 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] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809082
fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## 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.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
Summary:
Move the directory creation logic to the CLI. This needs to be processed by RNCodegen.js eventually.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618550
fbshipit-source-id: e7dc4f5fc37e5ad12b5c6ae8ea31fc9ef16d74b9
Summary:
The TurboModule system requires a lookup function to map the spec name (name used in JS) to the C++ TurboModule subclass. This is a pure C function. For now, generate one lookup function per set of modules found in the codegen schema.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618281
fbshipit-source-id: 889e07bdd4f2e5e93c4d14e60225f5b0c6683917
Summary:
The nested `.gitattributes` file in `packages/react-native-codegen/android/` caused some confusion on Linux and macOS, causing Git to show `packages/react-native-codegen/android/gradlew.bat` as modified (CRLF removed, LF added).
Instead of relying on repo-local `.gitattributes` files to convert endings in the working directory, the files should be committed to source control with the correct line endings in the first place. There is no reason to convert LF endings in .sh and many other file to CRLF on Windows (maybe this was an issue a long time ago, but unless Notepad is used this won't be a problem for practically all modern editors).
Also fixed the line endings of `scripts/launchPackager.bat` which was incorrectly committed as LF.
## Changelog
[Internal] [Fixed] - Line endings and .gitattributes
Pull Request resolved: https://github.com/facebook/react-native/pull/29792
Test Plan: Clone repo on Linux, macOS, and Windows, and make sure no modified files show up.
Reviewed By: fkgozali
Differential Revision: D23546135
Pulled By: mdvacca
fbshipit-source-id: 1572fcb959212f212b137066f1aa66f0bb6e86c3
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
## 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
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Ian Grayson
Luna Wei
Sota Ogo
Simon Farshid
Neil Dhar
enniel
Andrei Shikov
Jesse Katsumata
Liam Jones
Moti Zilberman
Tim Yung
rayzr522
Héctor Ramos
Joel Arvidsson
Tommy Nguyen
Gustavo Sverzut Barbieri
Michael Neeley
Anderson Mesquita
PastLeo
Kevin Gozali
Jakob Krigovsky
Gareth Knowles
Nicola Corti
Frieder Bluemle
Kai Dederichs
Xuan Huang
Janic Duplessis
pera
Matthew Gray
Stefan Wrobel
Kudo Chien
Michel Weststrate
Rui Ying
Danilo Bürger
Peter Argany
Michel Weststrate
Dulmandakh
Thibault Malbranche
Ramanpreet Nara
Craig Martin
Pavlos Vinieratos
Ivan Moskalev
empyrical
Mike Grabowski
Scott Ngan
Jason Safaiyeh
simek
Makar Kotlov
Eloy Durán
stealthanthrax
Christoph Nakazawa
