adding @react-navigation/drawer breaks v44 via Reanimated?

[acomito]

Summary

• start new expo project
• expo install @react-navigation/drawer
• expo install react-native-reanimated
• expo install react-native-gesture-handler
• add "react-native-reanimated/plugin" to babel config
• import @react-navigation/drawer and then createDrawerNavigator()

Error: Reanimated 2 failed to create a worklet, maybe you forgot to add Reanimated's babel plugin?

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

iOS

SDK Version (managed workflow only)

~44.0.0

Environment

  Expo CLI 5.0.1 environment info:
    System:
      OS: macOS 12.1
      Shell: 5.8 - /bin/zsh
    Binaries:
      Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
      Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.1/bin/yarn
      npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
    SDKs:
      iOS SDK:
        Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
    IDEs:
      Android Studio: 2020.3 AI-203.7717.56.2031.7935034
      Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
    npmPackages:
      expo: ~44.0.0 => 44.0.1
      react: 17.0.1 => 17.0.1
      react-dom: 17.0.1 => 17.0.1
      react-native: 0.64.3 => 0.64.3
      react-native-web: 0.17.1 => 0.17.1
    npmGlobalPackages:
      expo-cli: 5.0.1
    Expo Workflow: managed

Reproducible demo

https://github.com/acomito/expo-bug-44

[acomito]

possibly related to https://github.com/expo/expo/issues/15600 ?

[acomito]

Okay an update... I was able to get this working without an error

BUT

If i put the expo project inside of another project (as a monorepo), I get the error again. Consistently. I put it in that folder, I get it. I take it out, it's gone.

Really strange... any reason expo couldn't be in a monorepo? How would expo know it's sitting in a monorepo vs any other folder on my file system

[AlexMachin1997]

Yeah I'm also having problems with re-animated since upgrading to v44 of the Expo SDK.

This is the issue I'm seeing:

Not entirely sure what I'm missing....

[acomito]

Mine was very strange... it worked outside of our monorepo but not inside the monorepo. I could slide the project out of the monorepo, it worked. Slide the expo project folder back into the monorepo and run it... didn't work.

No idea how expo even knows what folder it is living in but I'm keeping it separate for now.

[cm-nutrien]

Monorepo issues are probably related to how your node_modules are hoisted. In a monorepo they tend to get pulled up into the root of the project but react native will be looking for many of its dependencies at the workspace/project level. Metro config is where to go to implement a fix for that I believe.

That said, its just one possible problem. I'm dealing with issues related to reanimated and upgrading to 43/44 myself and don't have answers beyond this suggestion.

[AlanSl]

I'm having a similar problem with react-native-reanimated via @react-navigation/drawer failing inside a monorepo.

@acomito have you followed the docs on setting up Expo inside a monorepo workspace https://docs.expo.dev/guides/monorepos/ (which includes metro config for checking both root and workspace dependencies)? And is your babel config including the reanimated plugin in the expo app workspace root, or in the monorepo root?

I've been getting something slightly different; I get the same "maybe you forgot to add Reanimated's babel plugin?" if the babel config is not in the workspace directory, but if it is, the whole build fails silently: expo logs hang at "Starting Metro Bundler" and the apps crash with generic "Something went wrong" messages and nothing in device logs (happens for me with reanimated v2.x and v1.x).

---

[edit]: my "failing silently" seems to be the "LAN" console swallowing the following opaque error, which is shown if I switch Expo UI to "Tunnel":

Error: EISDIR: illegal operation on a directory, read
    at Object.readSync (node:fs:721:3)
    at tryReadSync (node:fs:431:20)
    at Object.readFileSync (node:fs:477:19)
    at UnableToResolveError.buildCodeFrameMessage (/...repo-root/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:347:17)
    at new UnableToResolveError (/...repo-root/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:333:35)
    at ModuleResolver.resolveDependency (/...repo-root/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:211:15)
    at DependencyGraph.resolveDependency (/...repo-root/node_modules/metro/src/node-haste/DependencyGraph.js:413:43)
    at /...repo-root/node_modules/metro/src/lib/transformHelpers.js:317:42
    at /...repo-root/node_modules/metro/src/Server.js:1471:14
    at Generator.next (<anonymous>)

My best guess is that it's something to do with Expo's recommended babel config's api.cache setting somehow not being compatible with monorepos? Though I get the same with it set to true or false (and an error that its unconfigured if I omit the api.cache line).

[sean-m-oleary]

I have similar issues. Is there a resolution out there for this? We're dead in the water on our 44 upgrade because of this.

[naraB]

@acomito Could you share how you go it to work without an error?

[acomito]

Hi all, my only solution was to move expo outside of the monorepo. We didn't want to invest too much time figuring it out and it works fine outside of the monorepo.

[YogiHa]

having the same issue after upgrading to 44, in a project that expo is the root project (not having monorepo or any equivalent) :/

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.