* add privacy manifest to pod install
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
* add privacy manifest to hello world template
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
---------
Co-authored-by: Phillip Pan <phillippan@meta.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474
When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.
This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.
[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed
Reviewed By: dmytrorykun
Differential Revision: D49319256
fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478
When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.
Notice that bumping that setting generated other warning as some APIs have been deprecated.
[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods
Reviewed By: dmytrorykun
Differential Revision: D49274837
fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
Summary:
One of the limitations of the existing flow for the release crew is that they need to manually remember to publish all the other packages in the monorepo ahead of a new patch release - this PR modifies the logic for the bump-oss-version script (and makes it available via yarn) so that it will not run if:
* there are git changes lying around
* if some of the packages need a new release
it required a bit of refactoring to extract some portions of the logic from the bump-all-package-versions script, but I think the end result is pretty decent.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - improve bump oss script to allow less human errors
Pull Request resolved: https://github.com/facebook/react-native/pull/38666
Test Plan:
* checkout this branch
* comment L54 of bump-oss-version.js (to remove the check on the branch name)
* run `yarn bump-all-updated-packages`, verify that it works and that it detects that some packages have unreleased code
* run `yarn bump-oss-version -t asd -v asd` (the "fake" parameters are needed to pass the yargs check), verify that it will throw an error because it finds a package that has unreleased code
Reviewed By: mdvacca
Differential Revision: D48156963
Pulled By: cortinico
fbshipit-source-id: 2473ad5a84578c5236c905fd9aa9a88113fe8d22
# Conflicts:
# scripts/publish-npm.js
re-add the file
nit
# Conflicts:
# package.json
Summary:
The current `test-e2e-local` script had two bugs:
- On [this](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L219) line we were initializing a new RN project with the packed `react-native` created [here](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L211)
- We were updating the local RN version after running `npm pack` [here](https://github.com/facebook/react-native/blob/c1c22ebacc4097ce56f19385161ebb23ee1624b3/scripts/test-e2e-local.js#L214). This meant that the version inside the packaged `react-native-xyz.tgz` was not updated since we ran `pack` before updating it. This was fine since the `init` command was using the local `react-native` repository instead of the packed version.
## Changelog:
[INTERNAL] [FIXED] - Use packaged react-native in test-e2e-local script
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[INTERNAL] [FIXED] - Use packaged react-native in test-e2e-local script
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36703
Test Plan:
- Run `yarn test-e2e-local -t RNTestProject -p Android`. The command should succeed.
I am not completely sure how to double check that we are using the packed version. Locally, I have a `fsmonitor--daemon.ipc` in my `react-native/.git` that can't be copied. The `.git` folder would be copied only when `cli.js init` was called with the whole repository – which is how I found out about the issue in the first place.
Reviewed By: hoxyq
Differential Revision: D44504599
Pulled By: cipolleschi
fbshipit-source-id: e57e2858bab46d4f978eed3cbaf3e504138594b8
# Conflicts:
# scripts/test-e2e-local.js
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36421
Changelog: [Internal]
Adding an extra choice for commit question, user can now choose between three options:
1. Commit with generic message, no further actions needed
2. Commit with custom message, intercative VIM input will open
3. Not committing anything
Reviewed By: cortinico
Differential Revision: D43943526
fbshipit-source-id: 014215105d192961486b7d1c697f491697492812
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36348
Changelog: [Internal]
Turns out that Phabricator strips `@` symbol from `@...` tags when exports commits to GitHub. Proposing to use `#` instead.
#publish-packages-to-npm
Reviewed By: cortinico
Differential Revision: D43712415
fbshipit-source-id: 86fc728eb0cb63afb6a9fe592a9ae998da2ce2e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36004
Changelog: [Internal]
This fixes CircleCI job, which is responsible for publishing bumped packages. We should not check for `stderr`, apparently `npm` uses it to store debug information:
- https://github.com/npm/npm/issues/118#issuecomment-325440
So we've tried to use this on 0.71-stable before and it succesfully published one package, but have exited right after it because `stderr` was not empty
Reviewed By: cortinico, cipolleschi
Differential Revision: D42836212
fbshipit-source-id: 6f2a9a512121683268fe6aae6a187fccb8d9dfbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35679
The Codegen cleanup step was not always working due to an issue with the codegen folder path. It was working for RNTester, but not for apps created from the Template.
## Changelog:
[iOS][Fixed] - Fix path issue to properly run the codegen cleanup step
Reviewed By: jacdebug
Differential Revision: D42137600
fbshipit-source-id: ba4cb03d4c6eb17fda70a4aff383908d2e468429
Summary:
This PR introduce an automatic way to detect whether the user sets its podfile to use frameworks.
In this way, users don't have to install pods with a specific environment flag but they can rely on the standard Cocoapods usage
## Changelog
[IOS][ADDED] - Automatically detect whether use_frameworks! is used
Pull Request resolved: https://github.com/facebook/react-native/pull/35636
Test Plan:
- CircleCI is Green
- Added unit tests
- Tested locally with an app
Reviewed By: dmytrorykun
Differential Revision: D42029355
Pulled By: cipolleschi
fbshipit-source-id: 76c92133deabbda59603b043a4d542737f10f044
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35672
While working on some example, I discovered that the helper function `install_module_dependencies` was not adding the proper `-DRCT_NEW_ARCH_ENABLED=1` flag to the compiler flags.
## Changelog:
[iOS][Fixed] - Make sure to add the New Arch flag to libraries
Reviewed By: jacdebug
Differential Revision: D42131287
fbshipit-source-id: 68c492150ba4e4a2ec726b3e8b8a9c7842b543bc
Summary:
This PR adds a safety check in case the Cocoapod build script is not able to clean the build folder.
We had evidences where this process failed, and in this way the user has a clear and actionable message to fix its situation.
## Changelog
[iOS][Added] - Add message with instructions about what to do if the cleanup of the build folder fails.
Pull Request resolved: https://github.com/facebook/react-native/pull/35642
Test Plan:
I was not able to reproduce the issue locally.
The fix is not destructive, let's see if the amount of issues decreases.
Reviewed By: dmytrorykun
Differential Revision: D42067939
Pulled By: cipolleschi
fbshipit-source-id: 433dbfaec42a1bf460dc9a48051aa51ec6e12d16
Summary:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
* [LOCAL] fix: use META_CI instead of CI envvar
* META_CI -> REACT_NATIVE_CI
* Rename more occurences of CI to REACT_NATIVE_CI
* Use REACT_NATIVE_CI in rn-tester/Podfile
* Add REACT_NATIVE_CI to prepare_hermes_workspace
* revert: Use REACT_NATIVE_CI in rn-tester/Podfile
* Consume hermes-engine.podspec from sdks/hermes-engine
* Consume hermes-engine.podspec from sdks/hermes-engine. Update tests
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
# Conflicts:
# ReactCommon/jsi/React-jsidynamic.podspec
Summary:
See the issue at https://github.com/facebook/react-native/issues/32432#issuecomment-1242234121
This fixes a bizarre issue when using the GNU coreutils tools. There are very minor differences in the standard command-line tools on macOS and the GNU coreutils. The `cp` command has slightly different semantics across these operating systems, so this commit normalizes those differences and allows GNU coreutils to be used or the system native version of `cp`.
Fixes#32432
## Changelog
[General] [Fixed] - Allow GNU coreutils to be used to build projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35382
Test Plan: This change allows the use of the system or GNU coreutils verson of `cp`.
Reviewed By: cipolleschi
Differential Revision: D41532472
Pulled By: cortinico
fbshipit-source-id: f0fe5274d3828bf6099deceee797a82a6adfdcab
Summary:
Fixes https://github.com/facebook/react-native/issues/35429
This fix is fairly straightforward. Instead of hardcoding two separate paths for this repo or a simple user's project, we ask Node to resolve `react-native-codegen`.
Because `react-native-codegen` is moved [into the `/packages/*` folder](https://github.com/facebook/react-native/blob/main/package.json#L104), it's part of a workspace in this repository. That means that this fix works not only for monorepos in general but also resolves the right path within the react native repository.
You can test this out yourself when running this command in either the root, or any other workspace in this repository:
```bash
node --print "require('path').dirname(require.resolve('react-native-codegen/package.json'))"
```
I've tested this on Node 16 and 18, and seems to work nicely. Note that you _**have to specify `react-native-codegen/package.json`**_. That's because the `react-native-codegen` package itself is technically invalid; it's missing an entry point within the package (no `main`). When running `node --print "require.resolve('react-native-codegen')"` Node can't resolve the main entry point, and will fail during this process.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix incorrect codegen CLI paths in monorepo projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35430
Test Plan: See PR https://github.com/facebook/react-native/issues/35429
Reviewed By: cortinico
Differential Revision: D41475878
Pulled By: cipolleschi
fbshipit-source-id: f0c362b64cf9c3543a3a031d7eaf302c1314e3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
Riccardo Cipolleschi
Riccardo Cipolleschi
Ken Tominaga
Marek Fořt
Thibault Malbranche
Lorenzo Sciandra
Lorenzo Sciandra
Tommy Nguyen
Ruslan Lesiutin
Ruslan Lesiutin
Ruslan Lesiutin
Riccardo Cipolleschi
Nick Gerleman
Dmytro Rykun
Steve Shreeve
Cedric van Putten
Dmitry Rykun