Unable to use in React Native due to import.meta not being supported

[malord]

React Native's Hermes JavaScript engine doesn't support import.meta and exits with an error at compile time, so testing for its existence in code doesn't work. I'm tempted to file a bug for this against Hermes but wondered whether any way around this already existed for Zustand?

[dai-shi]

If import.meta isn't supported, it means ESM isn't supported, I guess.
So, RN's Hermes should use CJS instead of ESM. (But, I don't think it's ideal.)

Our intentional workaround is to use "module" condition instead of "import" condition, but I'm afraid Hermes doesn't support those conditions in the first place. 🤔

@barelyhuman Do we have similar issues reported? We use the same config across zustand/jotai/valtio, and I suspect there are RN users who use Hermes...

[zgid123]

I am not sure, but it seems if I use config.resolver.unstable_conditionNames = ['require'];, expo-router file-based router won't work

[dai-shi]

That's interesting. I expected if conditionNames are ['require'] it will fallback to "default".

https://nodejs.org/docs/latest/api/packages.html#conditional-exports

---

Can you try config.resolver.unstable_conditionNames = ['require', 'default'];?

[zgid123]

still raise error [Error: URL.pathname not implemented]

[zgid123]

this config can make zustand to work for expo when enablePackageExports is enabled

config.resolver.unstable_conditionNames = [
  'browser',
  'require',
  'react-native',
]

[owencraston]

I have been debugging this for two days. This finally fixed my issue when working in my turbo monorepo with expo. Thank you!

[jvliwanag]

Coming here as a user of Jotai but having ran into the same issue.

First off, this issue is only apparent when using the metro config resolver.unstable_enablePackageExports with the default config from expo. Without unstable_enablePackageExports, metro skips reading exports and just uses the packages' main which points to commonjs. Moreover, metro/react-native doesn't look at the esm/import export by default, but the default expo config adds it here.

From here, metro runs by the resolver.unstable_enablePackageExports and resolver.unstable_conditionsByPlatform which ends up in runtime as Set('react-native', 'require', 'import', 'default') at least on expo projects. Take note that this is a set -- and the order on the config on metro doesn't matter. See closed metro issue.

A fix for expo users with unstable_enablePackageExports enabled is to add either require or react-native as the first entry per export. It cannot go after import, otherwise it will be import that's used.

// in package.json
   ".": {
      "require": {
        "types": "./index.d.ts",
        "default": "./index.js"
      },
      "import": {
        "types": "./esm/index.d.mts",
        "default": "./esm/index.mjs"
      },
      "default": {
        "types": "./index.d.ts",
        "default": "./index.js"
      }
    },
    "./*": {
      "require": {
        "types": "./*.d.ts",
        "default": "./*.js"
      },
      "import": {
        "types": "./esm/*.d.mts",
        "default": "./esm/*.mjs"
      },
      "default": {
        "types": "./*.d.ts",
        "default": "./*.js"
      }
    }

Patching my local version, i've confirmed this to work on local projects.

Note that while i've veered away from turning on unstable_enablePackageExports in the past, I believe the intention of the metro team is to enable this by default in the future. Also, my migration to storybook 8 on react native ends up turning this on.

[dai-shi]

I believe the intention of the metro team is to enable this by default in the future.

Do you think they are gonna do it without supporting import.meta?

[jvliwanag]

I'm afraid I don't know. Asked this on hermes discussion.

[jvliwanag]

ESM native support noted here.