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
Summary:
This is a backport of [this](https://github.com/facebook/react-native/commit/becb47ccb6a6ed77e81b5488561ef6d683933ffe) local fix we made on
0.71-stable.
All our podspecs delegates to the main React Native pods script to set up the dependencies properly. The React-Codegen.podspec, which is generated by
the script itself, was generated with hardcoded dependencies. This PR aligns the versioning with the other podspec.
On a side note, this could create issues in CI and when releaseing, because we are changing the versions to prepare the new release and it breaks some
steps.
## Changelog
[iOS] [Fixed] - Make sure that the React-Codegen.podspec does not enforce specific versions of its dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/35274
Test Plan:
1. Ruby tests are passing
2. Manually tested that pods are correctly installed in the following configurations
- RNTester - Hermes - Old Architecture
- RNTester - Hermes - New Architecture
- RNTester - JSC - Old Architecture
- RNTester - JSC - New Architecture
Reviewed By: christophpurrer
Differential Revision: D41153859
Pulled By: cipolleschi
fbshipit-source-id: 043513866a66ecca3e326f8671bea3ec576422de
# Conflicts:
# scripts/cocoapods/codegen_utils.rb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
This PR makes sure that the `preapre_package_for_release` script fail fast if there is already a tag for the desired version
on github.
## Changelog
[General] [Added] - Make the `prepare_package_for_release` fail if there is already a git tag with that version
Pull Request resolved: https://github.com/facebook/react-native/pull/35305
Test Plan:
Tested manually. The script is currently only invoked during the release process.
<img width="1238" alt="Screenshot 2022-11-10 at 12 24 03" src="https://user-images.githubusercontent.com/11162307/201090947-274c1b1c-0b6a-4619-bc85-fa60e5eaeee1.png">
Reviewed By: cortinico
Differential Revision: D41403159
Pulled By: cipolleschi
fbshipit-source-id: fb87df345b14568c750482e5c68be53551a9acbb
# Conflicts:
# scripts/release-utils.js
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35379
This diff moves the publishing coordinates from:
```
com.facebook.react:react-native
com.facebook.react:hermes-engine
```
to
```
com.facebook.react:react-android
com.facebook.react:hermes-android
```
I've picked those they are the most layout friendly when building from source, but we can discuss if we want others.
I've updated the Gradle plugin to have a dependencySubstitution rule + update the template with those changes.
It should now be possible to still use `implementation("com.facebook.react:react-native:+")` inside libraries
on 0.71+ and RNGP will resolve dependencies correctly.
Changelog:
[Android] [Changed] - Void the Maven coordinates for react-native and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D41380525
fbshipit-source-id: 91e059fa261acb89bee7ca0c79c30c3d856a2c80
Summary:
Fixes missing/incorrect devDependencies in a newly built app. The previous set did not pull in prettier, causing linting to fail. There was a peerDependency warning on yarn install. We also saw a separate lint warning at runtime specific to TS 4.9 being pulled in now, so we constrain in that version a bit.
Prettier and preset-env versions match the constraints and lockfiles of other RN packages.
## Changelog
[General] [Fixed] - Fixup template devDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/35372
Test Plan:
Created a new app targeting 0.71 via `react-native init`.
1. `yarn install --force` no longer shows warnings
2. `prettier` is installed, `yarn lint` no longer fails, and shows no warnings or errors
3. ~Tentatively a test step to add tests against linting in new app, but last time doing that in CircleCI led to timeouts with no output that I didn't have time to debug, so maybe that's fixed now? �♀️.~ (edit: still hangs)
Reviewed By: NickGerleman
Differential Revision: D41363021
Pulled By: lunaleaps
fbshipit-source-id: d6163b01e8934d75a231fa0fd849d7bde7b3500c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35285
While doing the release 0f 0.71.0-RC0, we noticed that having the RN version in the hermes tarball was causing more harm than good.
With the version in the name, we ended up with multiple tarballs for debug and release and we were not able to explicitly pick the right tarball given a build.
This change remove the version from the tarball name.
## Changelog
[General][Changed] - Remove React Native version from Hermes tarball name
Reviewed By: lunaleaps
Differential Revision: D41156353
fbshipit-source-id: 8899d5e1e1555bc728d923f3b78d1261e6ff09c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
# Conflicts:
# scripts/cocoapods/__tests__/codegen_utils-test.rb
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Lorenzo Sciandra
Lorenzo Sciandra
fortmarek
Ruslan Lesiutin
Riccardo Cipolleschi
Ruslan Lesiutin
Tommy Nguyen
Ruslan Lesiutin
Riccardo Cipolleschi
Nick Gerleman
Dmytro Rykun
Steve Shreeve
Cedric van Putten
Dmitry Rykun
David Angulo
Nicola Corti
Nick Gerleman
Oleksandr Melnykov
Christoph Purrer
