How to debug blank screen issue with no error output?

[ospfranco]

Hi, I'm starting to try repack and the documentation is scarce when it comes to per app issues. I just tried starting my app and after "fixing" some typescript transpilation issue with some of the dependencies I'm now facing a blank screen with no apparent cause.

I'm not exactly looking for a solution (though I would appreciate it if anybody has one) but rather, how would one debug such an issue:

[jbroma]

Hi @ospfranco,

from the logs in console it seems that there are some issues with module resolution happening (similar to #619). I can see that in both cases react-native-web is present in logs, while it clearly shouldn't be.

As to how to debug such errors - in this case, we are not displaying compilation issues in the app like Metro does, that's why it's so ambiguous.

[ospfranco]

I don't even have react-native-web in my dependencies, I wonder how it got there. In any case, without any info it's hard to know which steps should I take to solve it.

[jbroma]

I think it some kind of import inside of reanimated pointing to it and that how it gets involved into all of this.

I agree it's hard, I'm in the process of writing a guide on how to deal with module resolution issues and this is a nice example to showcase indirect cases of module resolution issues like this one.

[jbroma]

After a closer look, the warnings can be safely ignored there (the react-native-web imports in node_modules/react-native-reanimated/src/reanimated2/js-reanimated/index.ts are wrapped with try catch blocks).

Can you share your repro so we can get to the bottom of this?
I was able to run the new CLI app with Re.Pack and reanimated without any issues

[jbroma]

I can reproduce the same behaviour in metro:

This is done through commenting out AppRegistry.registerComponent(appName, () => App); to reproduce the invariant from the logs.

Disabling bridgeless in AppDelegate.mm results in error being displayed:

cc @ospfranco

[ospfranco]

I did not notice bridgeless was turned on. However, after turning it off I still do not get any meaningful error:

[jbroma]

Is it any better when using metro by any chance? (remember to filter out command overrides like this)

[ospfranco]

Yeah metro builds just fine even with bridgeless

[jbroma]

Looks like some kind of edge-case incompatibility with core, any chance you could create a minimal repro?

[ospfranco]

I did add a internal turbo module following this guide which might be outdated but did not find any more info.

I'm trying to create a reproducible example.

[ospfranco]

Ok, managed to reproduce it:

https://github.com/ospfranco/repack-error

You need to install the pods with the new arch, you can just do yarn pods.

[jbroma]

Thanks, I'll look into it. In the mean time I've opened an issue in core:
facebook/react-native#44572

[jbroma]

@ospfranco

I've tried running the app but couldn't reproduce it - it runs fine after taking into account the following:

• I've installed pods using this method:

  bundle install
  cd ios
  RCT_NEW_ARCH_ENABLED=1 bundle exec pod install

  Please note that this resulted in using CocoaPods 1.14.3 instead of 1.15.2 as it was in your case
• needed to comment out NativeSampleModule.h in AppDelegate.mm since it wasn't present and the ios compilation failed becaused of that

After that, the app works with everything rendering properly (even in bridgeless)

Here's the diff (without Gemfile.lock):

diff --git a/ios/Podfile.lock b/ios/Podfile.lock
index 8b36529..d2849eb 100644
--- a/ios/Podfile.lock
+++ b/ios/Podfile.lock
@@ -1455,8 +1455,8 @@ SPEC CHECKSUMS:
   ReactCommon: f42444e384d82ab89184aed5d6f3142748b54768
   SocketRocket: abac6f5de4d4d62d24e11868d7a2f427e0ef940d
   SwiftyRSA: 8c6dd1ea7db1b8dc4fb517a202f88bb1354bc2c6
-  Yoga: 348f8b538c3ed4423eb58a8e5730feec50bce372
+  Yoga: b9a182ab00cf25926e7f79657d08c5d23c2d03b0

 PODFILE CHECKSUM: 59af8010acfd5e8e187bbab56f8dc54cd4952209

-COCOAPODS: 1.15.2
+COCOAPODS: 1.14.3
diff --git a/ios/blahblah/AppDelegate.mm b/ios/blahblah/AppDelegate.mm
index 56e1ef1..e21d090 100644
--- a/ios/blahblah/AppDelegate.mm
+++ b/ios/blahblah/AppDelegate.mm
@@ -1,6 +1,6 @@
 #import "AppDelegate.h"

-#import <NativeSampleModule.h>
+// #import <NativeSampleModule.h>
 #import <React/CoreModulesPlugins.h>
 #import <React/RCTBundleURLProvider.h>
 #import <ReactCommon/RCTTurboModuleManager.h>

[ospfranco]

Interesting, maybe i built the wrong project. Which bife version are u using?

[jbroma]

what do you mean by bife?

I'm on Sonoma 14.5 / Xcode 15.3 / Ruby 2.7.6 / Node 20.12.2

[ospfranco]

Sorry, meant node. I was on the phone. I cannot reproduce it on a new project, even when I copied all the same dependencies, I will have to take a deeper look and copy file by file. I will let you know if I manage to isolate the issue.

[ospfranco]

Ok, finally managed to reproduce the issue in the example:

It seems to be happening because of Sentry.wrap. Project is updated.

[jbroma]

I managed to get it working by simply adding this to webpack.config.js, so that the sentry dependencies are properly transpiled:

diff --git a/webpack.config.mjs b/webpack.config.mjs
index 4f19a6f..337c804 100644
--- a/webpack.config.mjs
+++ b/webpack.config.mjs
@@ -161,6 +161,7 @@ export default (env) => {
             /node_modules(.*[/\\])+metro/,
             /node_modules(.*[/\\])+abort-controller/,
             /node_modules(.*[/\\])+@callstack[/\\]repack/,
+            /node_modules(.*[/\\])+@sentry/,
           ],
           use: 'babel-loader',
         },

I've also noticed that Sentry includes a custom serializer, so that part certainly won't work fully until it's ported to webpack env. But the app launches and throws some warnings now, so it shouldn't be an issue now

[ospfranco]

It seems I'm still getting an error, even after adding the @sentry package.

Probably some other dependency which is not properly transpiled. Is there any possibility to catch the errors early and show which import is crashing?

[jbroma]

The only other difference is the Gemfile.lock and Podfile.lock (used CocoaPods 1.14.3 vs 1.15.2 like before). Perhaps you can try adjusting that and see if that helps?

Generally it's hard to catch errors like this early, it's usually errors likes variable being undefined, or a class keyword being present in one of the files and causing an error, or worse - failing silently. In next major we plan to transpile every node_module so this shouldn't be an issue anymore.

[jbroma]

You can also try transpiling every node_module by changing the module rules to include: /node_modules/, to see if that solves the issue.

[ospfranco]

Tried both cocoapods 1.14.3 and include /node_modules/ none seem to work. I guess I have to keep spelunking. Thanks a lot for the help so far!

[jbroma]

Sure thing! If you manage to find other cause for this, then we can resume finding the root cause

Can you please check if this fixed the issue in the repro for you? From the error above I can see that it's the other app with the error.