Texture loading fails in @react-three/drei/native with Expo 53 due to unpatched BlobManager usage

[iyibu]

It seems that @react-three/drei/native's useGLTF is currently broken on Expo SDK 53 and React 19 due to an outdated usage of BlobManager. Although this has been patched in the latest commit of @react-three/fiber/native, it's not yet published. Combined with the way @react-three/drei/native imports textures, this results in a runtime error and prevents GLTF models from loading correctly.

I confirmed this behavior using the example from https://github.com/CodyJasonBennett/r3f-rn-simple/tree/master with the following package versions:

"dependencies": {
  "@expo/metro-runtime": "~5.0.4",
  "@react-three/drei": "^10.5.1",
  "@react-three/fiber": "^9.2.0",
  "expo": "^53",
  "expo-gl": "~15.1.7",
  "expo-status-bar": "~2.2.3",
  "react": "19.0.0",
  "react-dom": "19.0.0",
  "react-native": "0.79.5",
  "react-native-web": "~0.20.0",
  "three": "^0.167.1"
},
"devDependencies": {
  "@babel/core": "^7.26.0"
}

Additionally, I manually patched the following files under node_modules/@react-three/fiber/native/dist/ by updating the BlobManager import as follows (applied to all builds just in case):

• react-three-fiber-native.cjs.dev.js
• react-three-fiber-native.cjs.prod.js
• react-three-fiber-native.esm.js

const BlobManagerModule = require('react-native/Libraries/Blob/BlobManager.js');
const BlobManager = BlobManagerModule.default ?? BlobManagerModule;

Also, I noticed that if the import:

import { useGLTF } from '@react-three/drei/native'

is changed to:

import { useGLTF } from '@react-three/drei'

(i.e., removing "native"), everything works correctly with Expo Go, Expo SDK 53, and React 19!

In summary:

• If the latest commit on @react-three/fiber/native is published, and
• If the bug in @react-three/drei/native is fixed,

then the following issues will be resolved:

• Texture loading failures
• a.k.a url.lastIndexOf is not a function error
• a.k.a Error: Creating blobs from 'ArrayBuffer' and 'ArrayBufferView' are not supported error

Thank you very much. Best regards.

@CodyJasonBennett @krispya

Originally posted by @iyibu in #3550

[iyibu]

Sorry for the repeated spam.

I’ve just discovered that the issue is also resolved when I set config.resolver.unstable_enablePackageExports = false in metro.config.js, even when importing from @react-three/drei/native.

It seems that the Metro (or Expo idk) import resolution mechanism for @react-three/drei/native and @react-three/drei has likely changed recently.

[krispya]

Looks like the same change made in pmndrs/react-three-fiber#3498 will fix the issue here, yes?

[iyibu]

Hello @krispya,

Yes, if a new version of @react-three/fiber is released that includes the PR you mentioned, there will be no need to manually apply the patch.

However, for the config.resolver.unstable_enablePackageExports = false workaround to become more stable, the package export in @react-three/drei (and also @react-three/drei/native) needs to be fixed. That way, we won't need to rely on this config anymore.
Since it's marked as unstable_, unfortunately, there's a chance it might be removed in the near future.

For this reason, I’ve opened a new issue on @react-three/drei.

By the way, I’ve seen that the community has already started using workarounds like "loading the texture and model separately" or "using Expo assets".
Personally, I find those approaches a bit too cumbersome.
That’s why this fix was quite important to me.
I’m really glad we were able to find at least a partial solution. Now it's time to move toward a more stable one :)

Best regards.

[thejustinwalsh]

Adding an exports field to the root package.json or adding a package.json with a main field to @react-three/drei/native will fix this.

The latest metro release has changed default package resolution and sets unstable_enablePackageExports to true by default. The resolution logic is determined by if require or import was used for the initial import that kicked off the resolution chain, and there are some quirks.

import { useGLTF } from '@react-three/drei/native'

This resolves to importing @react-three/drei/native/index.js using es module resolution.

import { useGLTF } from '@react-three/drei'

This resolves to importing @react-three/drei/native/index.cjs.js using the fallback resolution.
While we still started with es module resolution here, there is a package.json at the root of this folder that is overriding the es module resolution. When there is not an exports field in a package.json, metro will fallback to the previous resolution strategy and this matches the "react-native" field in the package.json which is set to native/index.cjs.js

This package is setup slightly differently than @react-three/fiber, where in @react-three/fiber/native there is a package.json which has an entry for main set to the cjs.js bundle. When you import @react-three/fiber/native metro is using the fallback resolution because there is no exports field, and it defaults to main on the fallback path.

Importing from import { useGLTF } from '@react-three/drei' is a completely fine solution, as it imports the correct file, but the differences between fiber and drei and the docs is confusing.

fwiw, this resolves the modules correctly, but types will not resolve correctly for fiber.

import { Canvas } from "@react-three/fiber";
import { useGLTF } from '@react-three/drei';

@krispya for consistency, we should add the exports field to the root fiber and drei packages with "react-native" entries pointing to the native imports, and we should add a package.json to the native folder in drei using the same technique that is used in fiber. That should support all possible combinations of imports, moving forward, i don't believe there is a need to import from the native path directly with the latest changes to expo 53 and metro.

[thejustinwalsh]

For clarity the actual bug that happens at runtime is that metro is resolving to the esm version, and importing three from it's esm import as well. This then results in two versions of three being imported, and we only patch the cjs version that was imported in fiber.

[CodyJasonBennett]

Introducing exports would constitute a breaking change. This is something we have been preparing for a while as three transitions to ESM-only, and R3F today cannot be resolved as ESM.

[thejustinwalsh]

I can work up the PR for the package.json in the native folder for drei.

[github-actions]

🎉 This issue has been resolved in version 10.6.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀