search

react-native-community / releases

React Native releases
https://github.com/facebook/react-native/
1.5k stars 405 forks source link

Road to v0.64 Discussion #214

Closed grabbou closed 3 years ago

grabbou commented 3 years ago

Current latest release: v0.64.0-rc.4

Highlighted Changes

Please see the changelog PR for more details.

Work Required

Already resolved - [X] [Update documentation](https://github.com/facebook/react-native-website/projects/1) [@simek] - [x] facebook/react-native#29914 - [x] React 17 support (landed) - [x] facebook/react-native#29882 - [x] facebook/react-native#30177 - [x] facebook/react-native@a7c1c5a - [x] Bump CLI to latest - [x] Migrate warnings in index.js to point to new lean core repos (https://github.com/facebook/react-native/pull/30422) - [x] The `hermes-engine` pod has no version constraints specified, which should probably happen in the `React-Core.podspec` file and lock it with similar version constraints as the one applied to the Android version in `package.json`. Fixed by https://github.com/facebook/react-native/pull/30432 - [x] The newly introduced codegen invocation step in the iOS Podfile is failing, as the dependencies of the `react-native-codegen` package have not been installed. See output [here](https://gist.github.com/alloy/2d3b3285b76666234be62086f9d4b8b6). In progress PR here https://github.com/facebook/react-native/pull/30449 - [x] Trying to build a newly created Android app fails when checking the dynamic libraries for duplicate classes. See output [here](https://gist.github.com/alloy/a9f2f4102705bad0b2c53407edd2bd89). Fixed by https://github.com/facebook/react-native/pull/30452 - [x] https://github.com/facebook/react-native/pull/30470 - [x] The new CLI has a minor regression when using a local template dir, now you need to specify the `file://` protocol to resolve that [@grabbou] (added note to changelog, this is expected) - [x] https://github.com/facebook/react-native/commit/d85d5d2e1974b463318e4c86da29a5ccdd60a977 - [x] facebook/react-native#30489 (+ make sure to update the changelog as [per this comment](https://github.com/facebook/react-native/pull/30489#pullrequestreview-539864503)) - [x] Bump to Hermes 0.7.2 (facebook/hermes#373) (https://github.com/facebook/react-native/pull/30561) - [x] Add instructions on how to enable Hermes in the default application https://github.com/facebook/react-native/pull/30461 - [x] Running `pod install` outside of `ios` folder will fail facebook/react-native#30469 (temporary solution, will be fixed by facebook/react-native#30449) - cherry picked https://github.com/facebook/react-native/commit/c901c1fbce080c6e9b6ed56dbccaa7f2fa0571b2, https://github.com/facebook/react-native/commit/5eee2f2bc01184481a663453648ab15d1d295f4d and https://github.com/facebook/react-native/commit/b61aaa1545b3308bda5ade169204f875ba417f01 for the record. - [x] ~~Submitting Hermes enabled application to AppStore will fail validation https://github.com/facebook/hermes/issues/420~~ This isn't a release blocker; this issue is triggered when somebody specifies a higher deployment target than the default and can be solved by the user as shown [here](https://github.com/facebook/hermes/issues/420#issuecomment-736875843). - [x] https://github.com/facebook/react-native/pull/30571 - [x] Building React Native application in release mode will cause an issue with Xcode 12 facebook/react-native#29984 (here [is a workaround](https://github.com/facebook/react-native/issues/29984#issuecomment-696328815)) https://github.com/facebook/react-native/pull/30543 - [x] facebook/react-native#30495 (regression) - [x] Building with Hermes in Release mode (or with "build active architecture" set to false) causes "Thread-local storage is not supported for the current target" in "folly/synchronization/Rcu.cpp:17:10:" and happens while building for "i386". https://github.com/facebook/react-native/pull/30592 - [x] Resolve issues highlighted in the comment https://github.com/react-native-community/releases/issues/214#issuecomment-758203239 - [x] https://github.com/facebook/react-native/commit/811ccec74e5b898e9304f86f85f390908f8d317f - [x] https://github.com/facebook/react-native/commit/7a9e4ba4e9ae02ab8a0fe0f67ceefd5d675b9dbf - [x] https://github.com/facebook/react-native/commit/f312e5ba84afcddaac326ed62eaf4e00c00cf480 - [x] https://github.com/facebook/react-native/commit/f45cb60e560d21be134aa808bd105e0394ba1fd5 - [x] Issue stripping symbols on Android https://github.com/react-native-community/releases/issues/214#issuecomment-758425571 - [x] Some users are experiencing issues with CodeGen on iOS due to missing files https://github.com/react-native-community/releases/issues/214#issuecomment-766436299

Hopeful Dates

We can never commit to the dates involved in a release as many things are out of our control. However, we are thinking about these rough dates for this release.

cosmarc commented 3 years ago

Compiling the default generated app with 0.64-rc.2 gives the following errors:

RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:16:28: error: cannot find protocol declaration for 'NativeVibrationSpec'
@interface RCTVibration() <NativeVibrationSpec>

RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:20: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:49: error: type name requires a specifier or qualifier
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:33:72: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/Vibration/RCTVibration.mm:35:27: error: use of undeclared identifier 'facebook'
  return std::make_shared<facebook::react::NativeVibrationSpecJSI>(params);

RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:27:33: error: cannot find protocol declaration for 'NativeLinkingManagerSpec'
@interface RCTLinkingManager() <NativeLinkingManagerSpec>

RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:20: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:49: error: type name requires a specifier or qualifier
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:188:72: error: use of undeclared identifier 'facebook'
- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const facebook::react::ObjCTurboModule::InitParams &)params

RN064/node_modules/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm:190:27: error: use of undeclared identifier 'facebook'
  return std::make_shared<facebook::react::NativeLinkingManagerSpecJSI>(params);

As well as:

fatal error: module map file '/Users/username/Library/Developer/Xcode/DerivedData/RN064-fpnzltspmimnjpcudwlvlpjgalym/Build/Products/Debug-iphonesimulator/YogaKit/YogaKit.modulemap' not found
ghoudi01 commented 3 years ago

app size increase after enabling Hermes in ios

lumberman commented 3 years ago

On the latest RC2 release, failed to build via command line with the next error: The following build commands failed: CompileSwift normal x86_64 /Users/xxx/GitHub/xxx/ios/Pods/YogaKit/YogaKit/Source/YGLayoutExtensions.swift CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (2 failures)

But works well using XCode.

miinos commented 3 years ago

On the latest RC2 release, failed to build via command line with the next error: The following build commands failed: CompileSwift normal x86_64 /Users/xxx/GitHub/xxx/ios/Pods/YogaKit/YogaKit/Source/YGLayoutExtensions.swift CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (2 failures)

But works well using XCode.

same for me

shaikhaffan commented 3 years ago

Hi Folks,

I was able to upgrade successfully my react native application without much trouble. initially i faced few issues, but reinstalling node_modules, regenerating pods helps to upgrade it successfully.

lorenzoangelini commented 3 years ago

I'm trying to upgrade to RN 0.64-rc.02, on android i don't have issues. On ios during the archive process, i encountered this error:

Screenshot 2020-12-22 at 14 41 15

I can replicate the error on both pipe and local pc.

mrousavy commented 3 years ago

@lorenzoangelini looks like you're using codepush 🤔 CodePush + Hermes isn't supported on iOS yet, see https://github.com/microsoft/react-native-code-push/issues/1986 and https://github.com/microsoft/react-native-code-push/issues/1966 (or https://github.com/microsoft/appcenter-cli/issues/1164)

lorenzoangelini commented 3 years ago

Hi @mrousavy i don't use codepush. If i disable hermes the archive works.

lorenzoangelini commented 3 years ago

@grabbou this pr, https://github.com/facebook/react-native/pull/30470, is present into RN 0.64.0-rc.2? Because after the upgrade, the app crash on start uo in release mode with hermes enabled. (on android). Without hermes, the app doesn't crash. But on RN 63.4, with hermes enabled, i don't have any issue.

EDIT: I found the problem, I use this https://github.com/react-native-community/jsc-android-buildscripts it seems that it is not supported in RN 0.64.0. I solved it by removing the library

lumberman commented 3 years ago

With hermes enabled it can't find FBReactNativeSpec/FBReactNativeSpec.h file in RCTVibration.mm. Disabling hemes solves the problem. Looks like the issue caused by some third-party pod as it was working fine initially. Also, libevent generating a crazy amount of warnings while compiling.

beetlebum commented 3 years ago

'FBReactNativeSpec/FBReactNativeSpec.h' file not found I have this same issue, although in my case it's complaining at React-RCTAnimation.build. If you clean the iOS project and recompile, it works again (I use react-native-clean-project and wipe iOS build folder option).

persist-xyz commented 3 years ago

NativeVibrationSpec

i have the same issue, any solution please?

KingAmo commented 3 years ago

'FBReactNativeSpec/FBReactNativeSpec.h' file not found I have this same issue, although in my case it's complaining at React-RCTAnimation.build. If you clean the iOS project and recompile, it works again (I use react-native-clean-project and wipe iOS build folder option).

maybe related to https://github.com/facebook/react-native/issues/30257 ? or https://github.com/facebook/react-native/pull/30449

kelset commented 3 years ago

hey folks - since we are now entering the ✨magical time✨ between Christmas and New Year, most of the maintainers are off on holidays; so I don't think there will be much going on here, or in terms of new commits or releases until January.

For all the issues you are reporting please open an issue on the main repo; it makes everyone's life easier to have the conversation for these kind of bugs somewhere else so that we can keep the one here on which commits to cherry pick (and just have here the link to said issues).

@KingAmo one thing in your comment on https://github.com/facebook/react-native/issues/30257 that caught my eye is that you are using npm@7 and I'm worried maybe also other folks here are having issues because of that.

Either way, again, please open an issue, and keep the conversation there.

Over and out, happy holidays everyone. See you in January.

KingAmo commented 3 years ago

@kelset i have a warning when run pod install in /ios folder:

[!] FBReactNativeSpec has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.
tido64 commented 3 years ago

@KingAmo

[!] FBReactNativeSpec has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.

That's just a warning for the codegen script that was added to FBReactNativeSpec. It can safely be ignored.

KingAmo commented 3 years ago

follow the upgrade helper from rc.1 to rc.2 solved 'FBReactNativeSpec/FBReactNativeSpec.h' file not found problem for me.

NickGerleman commented 3 years ago

Would appreciate it if we could cherry pick in facebook/react-native@6d2a527 The commit fixes an issue on iOS/macOS/Windows where clicks or taps are sometimes eaten when using a physical keyboard instead of soft keyboard.

I think this one might have gotten lost.

@NickGerleman I will check it tomorrow and let you know.

We ended up porting the fix to 0.63 for RN macOS and RN Windows, but are using stock bits for 0.64 so far. The issue is pretty bad for tablet or desktop usage, so it would be great if we could fix across platforms before release.

vmoroz commented 3 years ago

I would like to ask to cherry pick the https://github.com/facebook/react-native/commit/8aea93022bad4ed57ff6b738528a43f26fc335ac. It is a trivial change that removes an unnecessary TurboModule dependency on Folly. It would help us avoid forking TurboModule files in the react-native-windows where we are adding support for C++ TurboModules in https://github.com/microsoft/react-native-windows/pull/6804 .

Peeeep commented 3 years ago

Please consider cheery picking https://github.com/facebook/react-native/commit/381fb395ad9d2d48717a5d082aaedbecdd804554. It’s only a few lines and would greatly improve accessibility and the Android e2e testing experience so that the misuse of the accessibilityLabel can finally come to an end! Corresponding pull request was https://github.com/facebook/react-native/pull/29610

spyshower commented 3 years ago

Current latest release: v0.64.0-rc.1

Isn't 0.64.0-rc.2 the latest one? :P

polovi commented 3 years ago

I have errors based on the method how I init application. If I use upgrade tool from rc1 to rc2 errors are based on RCTClipboard

Screenshot 2021-01-11 at 17 48 30

If I init react-native app with --version rc2 errors are based on RCTVibration

Screenshot 2021-01-11 at 17 55 27
grabbou commented 3 years ago

It can't find FBReactNativeSpec/FBReactNativeSpec.h file in RCTVibration.mm.=

@lumberman @beetlebum right now, the CodeGen stuff is not run at pod install time, but after building the project. So indeed, before the first build, there might be some errors in the workspace.

CC: @hramos - not sure whether that is desired UX. Alternative would be to run this script while doing pod install anyway.

grabbou commented 3 years ago

@grabbou So I've tried to build android, but my builds failed because the turbo module JSI JNI .so files were generated more than once:

- More than one file was found with OS independent path 'lib/x86_64/libturbomodulejsijni.so'. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake

I temporarily fixed this, by adding this:

android {
     // ...

+    packagingOptions {
+        pickFirst '**/*.so'
+    }

     // ...
}

in my app/build.gradle (under the android { section). Since I'm not sure if that has any unwanted side-effects, I don't really feel comfortable with shipping an app like this, but it builds fine for now. (I couldn't get the app to actually run due to errors with reanimated - working on that! software-mansion/react-native-reanimated#1469)

@mrousavy do you have any update on this? Since I couldn't reproduce it, my question is - did you get it on a fresh new app?

mrousavy commented 3 years ago

@grabbou No, I had those errors in my app which worked fine on RN 0.63, but I think it's related to reanimated. I'll test again tomorrow 👍

grabbou commented 3 years ago

Hey!

I am back to work in 2021 after holidays! I had a run through comments today and checked the status of the release. I would like to get it out to you as soon as possible. We're not that far away, while it may look otherwise based on the list of issues below!

Issues to verify:

Regressions:

Cherry-pick requests:

I will start with the issues first. The plan is to resolve everything by 24th of January and push the latest release candidate before going stable.

TheSavior commented 3 years ago

The regression has a fix that has already landed on master: https://github.com/facebook/react-native/commit/4481d09865c728f08017687f9f2bbb0399d48e45

dulmandakh commented 3 years ago

I would like to propose to cherry-pick https://github.com/facebook/react-native/commit/6bfd89d27724f2aac602fa2acbf4753950f4152e to improve Android networking security. I expect no issues with this change.

SConaway commented 3 years ago

Not sure if this is related to https://github.com/react-native-community/releases/issues/214#issuecomment-758200295 or not, but I've noticed that there's an issue stripping symbols on Android in the latest RC. It happens in debug and release, with and without Hermes. Occurs on a freshly-created app running RN 0.64.0-rc.2. 

> Task :app:stripReleaseDebugSymbols
Unable to strip the following libraries, packaging them as they are: libc++_shared.so, libfb.so, libfbjni.so, libfolly_futures.so, libfolly_json.so, libglog.so, libglog_init.so, libhermes-executor-common-debug.so, libhermes-executor-common-release.so, libhermes-executor-debug.so, libhermes-executor-release.so, libhermes-inspector.so, libhermes.so, libimagepipeline.so, libjscexecutor.so, libjsijniprofiler.so, libjsinspector.so, libnative-filters.so, libnative-imagetranscoder.so, libreact_codegen_reactandroidspec.so, libreact_nativemodule_core.so, libreactnativeblob.so, libreactnativejni.so, libreactnativeutilsjni.so, libreactperfloggerjni.so, libturbomodulejsijni.so, libyoga.so.
grabbou commented 3 years ago

@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.

a-eid commented 3 years ago

I'm having this same issue https://github.com/react-native-community/releases/issues/214#issuecomment-758194436,

the same way it's noted in build.gradle that one should do a ./gradlw clean after changing enableHermes option, it should be noted in podfile that one should do a pod install after enabling /disabling hermes on ios.

hsavit1 commented 3 years ago

@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.

please elaborate on "shortly" - the 0.64 release took many months

Titozzz commented 3 years ago

@hsavit1 While I understand that you'd like things to move faster, I think everyone try to do their best to release good stable versions. If you want to work with the latest commits on master (like fb does), feel free to use the nightly builds, these are made for you. Also please keep this discussion to bug reports especially when we are that close to the release 😄 .

sunnylqm commented 3 years ago

@Titozzz By "nightly builds" do you mean build by oneself? But based on my personal experience, most of the time the master could not pass the build in the OSS repo (fb has a different internal version/build process I think and neither did they test or care about the OSS builds). Or did I miss something, is there any public nightly builds channel?

NickGerleman commented 3 years ago

@sunnylqm the react-native repo does publish nightly builds! The main consumer at this point is the react-native-windows project, because we want to validate and integrate new changes before they're released. These builds are published under the "nightly" dist-tag. E.g. https://www.npmjs.com/package/react-native/v/0.0.0-6fd684150

There is likely to be dragons with these, but reporting or fixing any issues affecting the public OSS build would be a great way to help make things smoother at release time.

sunnylqm commented 3 years ago

@NickGerleman Thanks for the info and surprised that I never heard of it! Maybe someone should note that somewhere like https://reactnative.dev/versions

Theofilos-Chamalis commented 3 years ago

Is this PR https://github.com/facebook/react-native/pull/29039 something that could be merged and cherry picked prior to the final release or maybe in the upcoming ones? It is a common issue that we have been facing on our team on our last 2 projects.

Adelahelen commented 3 years ago

I have switched to whatsapp gb long ago.

marudy commented 3 years ago

@grabbou I can confirm I am getting FBReactNativeSpec/FBReactNativeSpec.h file in RCTVibration.mm with hermes option disabled. Hermes does not seem to be problem. I am referring to this #214 (comment)

Did cleaned the project and the issue persists.

a-eid commented 3 years ago

@marudy you need to pod install again after enabling Hermes.

beetlebum commented 3 years ago

This is not related to Hermes as it's disabled in our build and we still experience this issue. I'm still seeing the error randomly pop up, although usually it goes away after a few tries cleaning the iOS build.

Could it be related to the order in which codegen and other compilation steps happen? there could be an extra migration step we're missing.

node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedModule.mm:8:9: fatal error: 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
#import <FBReactNativeSpec/FBReactNativeSpec.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
marudy commented 3 years ago

@a-eid yeah i am doing pod install every time. It's not the cause of the problem

ivanmoskalev commented 3 years ago

FBReactNativeSpec/* files actually get generated inside the node_modules/react-native/Libraries/<Library Name> directory, and not in the usual ${PODS_ROOT}/Headers/Public/<Library Name> where CocoaPods and Xcode expect them to be. This means that:

a) any operation that touches node_modules can destroy generated files; b) if other Pods depend on the FBReactNativeSpec target and are not configured to search for headers in the node_modules/react-native/Libraries/ dir, they will not be able to find generated sources.

The generated files are also not listed in the "Output Files" of the Xcode's Script stage. This may create issues with the Xcode's "New" build system, since it can nondeterministically run codegen after the build steps that implicitly depend on its results.

I guess these may play some role in the issues people are observing.

ivanmoskalev commented 3 years ago

Following up on my earlier comment – this change alone seems to help:

diff --git a/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec b/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
index 70e90d54ea439ef076c80c5d53d441919b5315a7..ef1ae65ae4482b90f5d063408d70f7e57abcf8e7 100644
--- a/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
+++ b/Libraries/FBReactNativeSpec/FBReactNativeSpec.podspec
@@ -59,7 +59,7 @@ Pod::Spec.new do |s|
   s.script_phase = {
     :name => 'Generate Native Modules Code',
     :input_files => [srcs_dir],
-    :output_files => ["$(DERIVED_FILE_DIR)/FBReactNativeSpec-codegen.log"],
+    :output_files => ["$(DERIVED_FILE_DIR)/FBReactNativeSpec-codegen.log"] + generated_files,
     :script => codegen_command,
     :execution_position => :before_compile
   }

At least it makes Xcode wait for codegen before proceeding with compilation of the FBReactNativeSpec target and its dependents.

It may still be problematic that the codegen results are put in node_modules and not in the DerivedData dir, though.

(The first thing that actually came to my mind is that codegen'ing into node_modules will complicate supporting PnP in Yarn v2, aka Berry, since it expects the dependencies' sources to be immutable)

UPDATE:

No, this change still doesn't solve the issue of generated files not existing during the time when pod install is run for the first time after a clean install. Since there are no files at this point yet, the FBReactNativeSpec target ends up having no sources.

djMax commented 3 years ago

I imagine this is the same problem discussed above, but on the off chance this variant is helpful, here's my version:

error: Build input file cannot be found: '/my-app/packages/mobile-app/node_modules/react-native/Libraries/FBReactNativeSpec/FBReactNativeSpec/FBReactNativeSpec-generated.mm' (in target 'FBReactNativeSpec' from project 'Pods')

I am using a monorepo, which perhaps is another twist. Also when trying to apply the diff, there are a NUMBER of pbxproj changes that mostly look cosmetic - ids changing etc. If there's any way to NOT have those spurious changes in the diff I think everyone who upgrades would be very appreciative.

grabbou commented 3 years ago

@dulmandakh I would prefer to not cherry-pick anything at this point, unless it's critical. Let's leave something exciting for the 0.65 that will be cut shortly after this one is out.

please elaborate on "shortly" - the 0.64 release took many months

@hsavit1 I know, 0.64 is taking a while to release due to many unexpected conditions, including New Years Eve and lots of holidays that happened in the meantime. I am really sorry that this one had extraordinary amount of delays, but due to the nature of release process, sometimes it gets particularly tricky.

Last week was my first week after holidays. It was also a busy time for our friends over at Facebook due to lots of internal things happening.

I am going to send an updated game plan later today (here's the comment). I hope that all outstanding errors can be fixed this week.

kuasha420 commented 3 years ago

@grabbou Don't stress too much about it. A wise man once said, 'a delayed release is eventually good, but a rushed one is forever bad.'.. I think it was Albert Einstein

grabbou commented 3 years ago

@marudy @beetlebum @ivanmoskalev @cosmarc @djMax, are you all running a fresh React Native app or an upgraded one? I am not able to reproduce any CodeGen-related errors on a fresh application, that would be caused by the place where the execution of the generator takes place.

I created a fresh application, opened it up with Xcode and had no errors. I've hit compilation and managed to run it on a simulator without any errors as well.

The reason I am asking is - maybe there's something additional and specific to your project (during upgrade) that a fresh app already has?

grabbou commented 3 years ago

Thank you for the answer @max-earnin, but this question is specifically targeted to quoted developers as they reported the same TurboModule-related issue. Are you running into the same problem as well? If yes, can you verify that everything works fine on your machine when starting a blank new project? That way, we can have a starting point.

beetlebum commented 3 years ago

@marudy @beetlebum @ivanmoskalev @cosmarc @djMax, are you all running a fresh React Native app or an upgraded one? I am not able to reproduce any CodeGen-related errors on a fresh application, that would be caused by the place where the execution of the generator takes place.

I created a fresh application, opened it up with Xcode and had no errors. I've hit compilation and managed to run it on a simulator without any errors as well.

The reason I am asking is - maybe there's something additional and specific to your project (during upgrade) that a fresh app already has?

I have a massive project with dozens of dependencies that was started with 0.61, it would be hard to replicate from scratch I reckon.

Here's a list of modules:

BVLinearGradient, RNCAsyncStorage, RNCClipboard, RNCMaskedView, RNCPicker, RNCPushNotificationIOS, RNDeviceInfo, RNFBAnalytics, RNFBApp, RNFBAuth, RNFBPerf, RNFBRemoteConfig, RNFastImage, RNGestureHandler, RNLocalize, RNPurchases, RNRate, RNReanimated, RNSVG, RNScreens, RNSentry, RNShare, ReactNativeAutogrowTextinput, lottie-ios, lottie-react-native, react-native-adjust, react-native-amplitude-analytics, react-native-date-picker, react-native-fbsdk, react-native-netinfo, react-native-onesignal, react-native-pdf, react-native-restart, react-native-safe-area-context, react-native-slider, react-native-splash-screen, react-native-text-input-mask, react-native-track-player, react-native-video, react-native-view-shot, react-native-viewpager, react-native-zendesk, and rn-fetch-blob

The error is always the following:

Code/GitHub/better-half-app/node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedModule.mm:8:9: fatal error: 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
#import <FBReactNativeSpec/FBReactNativeSpec.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

image

image

Interestingly, it does always go away if I get the error, then clean the iOS build project, do pod install and react-native run-ios again, although it's a very time consuming error since it compiles everything from scratch.

Hope this helps, thanks in advance.