v1.2.3 is no styling anything on iOS with no visible error logs

[rami-maalouf]

What happened?

I used the template from better-t-stack.dev with the command bun create better-t-stack@latest --template uniwind.

It works fine on Web, did not test on android but on iOS, v1.2.3 doesn't work.

As soon as I drop it to v1.2.2, iOS works.

Here's a walkthrough of the problem: https://youtu.be/EBFgjJcX134

Both Expo Go and Development build don't work on that version

Steps to Reproduce

bun create better-t-stack@latest --template uniwind

make sure uniwind is on v1.2.3

Snack or Repository Link

https://www.better-t-stack.dev/

Uniwind version

1.2.3

React Native Version

0.81.5

Platforms

iOS

Expo

Yes

Additional information

• I've searched for similar issues in this repository and found none

[github-actions]

This issue has been automatically closed because it lacks a clear, minimal reproduction that we can use to verify the reported bug.

[Brentlok]

Works first try. Maybe try clearing the metro cache? bun start -c

[stephanvane]

@Brentlok I'm having the same issue.

Doesn't matter if I add Uniwind in an existing expo project, using the npx create-expo-app -e with-router-uniwind command, or bun create better-t-stack@latest --template uniwind like @psycho-baller did. The moment 1.2.3 (or 1.2.4) is installed, nothing works, no errors whatsoever, just unstyled content.

Could you both share which versions of MacOS you are using? I'm using Sequoia (15.7.3).
Possibly the error will be solved once I upgrade MacOS, I can try that later, but maybe I can help debugging on Sequoia if someone could steer me in the right direction :)

To reproduce it's literally just initializing a new project, and changing the version. If it's working or you're machine, there must be some variation between our setups I guess

[Brentlok]

We have exactly 0 lines of native code in the open source version of uniwind. So the mac version shouldn't make a difference, because it's pure js library. You can try adding console logs in node_modules/uniwind/dist/metro/index.cjs line 74 there's a function called nativeResolver which replaces RN's built components with our implementation, and you can also try adding console.log in node_modules/uniwind/src/core/native/store.ts line 49 there's a reinit function which should be called at the start of the app to initialize uniwind with correct styles

[stephanvane]

Thanks for sending me in the right direction @Brentlok, really helpful! After placing the logs it was clear pretty quickly what was going on.

Between 1.2.2 and 1.2.3 the following code changed in packages/uniwind/src/metro/resolvers.ts
(a8c6e1e)

     const resolution = resolver(context, moduleName, platform)
     const isInternal = isFromThisModule(context.originModulePath)
-    const isReactNativeIndex = context.originModulePath.endsWith(
-        `react-native${sep}index.js`,
-    )
+    const isFromReactNative = context.originModulePath.includes(`${sep}react-native${sep}`)
+        || context.originModulePath.includes(`${sep}@react-native${sep}`)
 
-    if (isInternal || resolution.type !== 'sourceFile' || isReactNativeIndex) {
+    if (isInternal || resolution.type !== 'sourceFile' || isFromReactNative) {
         return resolution
     }

The new code checks if /react-native/ is present anywhere in the file-paths.

You can probably guess where I, as a developer learning about new libraries, placed my hello-world project...... in /Users/stephan/projects/react-native/hello-world/.

This caused isFromReactNative to be true for every single file, breaking the library.

That also explains why the bug was not reproducible by you. It only breaks if one of your parent folders is called react-native, which must have happend to @psycho-baller as well.

renaming the folder to something else resolves the issue (even though I do believe this is a bug, just not one that impacts everyone :) )

[Brentlok]

I've added simple check - if this file is in node_modules - #319
It will be released later today