Jest encountered an unexpected token after upgrading from 0.70 to 0.71

[koch10]

Description

After upgrading from expo SDK 47 to 48 and consequently upgrading react-native to 0.71.3, my jest tests are failing. The error is "Jest encountered an unexpected token" and the location can be seen in the screenshot.

I don't suspect that this has anything to do with firebase itself, but rather something to do with it being esm format.

After doing some(a lot) of trial and error i found that it breaks specifically between react-native@0.71.0-rc.2 and react-native@0.71.0-rc.3. That is, my jest tests pass just fine on 0.71.0-rc.2, but fail on 0.71.0-rc.3.

React Native Version

0.71.3

Output of npx react-native info

System:
OS: Windows 10 10.0.22621
CPU: (8) x64 Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Memory: 1006.46 MB / 7.82 GB
Binaries:
Node: 18.14.2 - C:\Program Files\nodejs\node.EXE
Yarn: Not Found
npm: 9.5.0 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK: Not Found
Windows SDK: Not Found
IDEs:
Android Studio: Version 2021.1.0.0 AI-211.7628.21.2111.8193401
Visual Studio: 16.11.31911.196 (Visual Studio Community 2019)
Languages:
Java: 17.0.3.1 - C:\Program Files\Common Files\Oracle\Java\javapath\javac.EXE
npmPackages:
@react-native-community/cli: Not Found
react: 18.2.0 => 18.2.0
react-native: 0.71.3 => 0.71.3
react-native-windows: Not Found
npmGlobalPackages:
react-native: Not Found

Steps to reproduce

Follow the guide on setting up an Expo project: https://docs.expo.dev/tutorial/create-your-first-app/
Then follow the guide on setting up jest for expo: https://docs.expo.dev/guides/testing-with-jest/

run "npx expo install firebase" in the terminal

Insert "import firebase from 'firebase/app';" into the App.test.js file

run "npm run test" in the terminal, and it should now give the error.

Snack, code example, screenshot, or link to a repository

Edit by @robhogan - example repro: https://github.com/robhogan/react-native-issue-36342

Here is the package.json

{
  "name": "jest",
  "version": "1.0.0",
  "main": "node_modules/expo/AppEntry.js",
  "scripts": {
    "start": "expo start",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "web": "expo start --web",
    "test": "jest"
  },
  "jest": {
    "preset": "jest-expo",
    "transformIgnorePatterns": [
      "node_modules/(?!((jest-)?react-native|@react-native(-community)?)|expo(nent)?|@expo(nent)?/.*|@expo-google-fonts/.*|react-navigation|@react-navigation/.*|@unimodules/.*|unimodules|sentry-expo|native-base|react-native-svg)"
    ]
  },
  "dependencies": {
    "@expo/webpack-config": "^18.0.1",
    "expo": "~48.0.4",
    "expo-status-bar": "~1.4.4",
    "firebase": "^9.17.1",
    "jest-expo": "^48.0.1",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-native": "0.71.3",
    "react-native-web": "~0.18.10",
    "jest": "^29.2.1"
  },
  "devDependencies": {
    "@babel/core": "^7.20.0",
    "@types/react": "^18.0.28",
    "@types/react-test-renderer": "^18.0.0"
  },
  "private": true
}

[cortinico]

After doing some(a lot) of trial and error i found that it breaks specifically between react-native@0.71.0-rc.2 and react-native@0.71.0-rc.3. That is, my jest tests pass just fine on 0.71.0-rc.2, but fail on 0.71.0-rc.3.

If this is the case, that this is most likely the culprit:

• fix(jest-env): pass exportConditions #35203

As it was picked for RC3

[koch10]

After doing some(a lot) of trial and error i found that it breaks specifically between react-native@0.71.0-rc.2 and react-native@0.71.0-rc.3. That is, my jest tests pass just fine on 0.71.0-rc.2, but fail on 0.71.0-rc.3.

If this is the case, that this is most likely the culprit:

• fix(jest-env): pass exportConditions #35203

As it was picked for RC3

Indeed it is. Just tried reverting the change and tests pass as they should.

[koch10]

Is this the expected behaviour, or should it be reviewed?

In any case, is there a cleaner workaround than simply just removing the change manually from the react-native library in the local node-modules folder?

[robhogan]

In any case, is there a cleaner workaround than simply just removing the change manually from the react-native library in the local node-modules folder?

As a workaround, you can run node_modules/@?firebase/ through the transformer by making this change to your package.json: robhogan/react-native-issue-36342@17cfcee

The root issue here is that RN's Jest environment now only exports react-native as an export condition (not node), which means packages which export a node target might now resolve differently. In the case of firebase, it defaults back to ESM. This should've been labelled as a breaking change to the Jest setup to be honest - sorry about that.

CC @huntie for Metro exports here as ideally the Jest setup should mirror Metro's as closely as possible. Are we planning to fall back to node or browser after react-native? @SimenB for awareness too.

[SimenB]

As mentioned in react-native-community/discussions-and-proposals#512, I think RN should have its own resolver and not rely on the one shipping with Jest at all. That way mirroring what Metro does should be easier

[huntie]

I think we can investigate this (following up on Jest is part of my Package Exports task list); however it might be a timeboxed effort for the time being. Otherwise, certainly something we can look at in future.

[moxen-dev]

Hey folks, how are you?

Same issue here. The fix mentioned (@?firebase) did the trick for me for testing components and other functions. Unfortunately testing firebase rules (using @firebase/rules-unit-testing) now exceeds timeout every time, no matter the timeout length (I tried up to 30 seconds).

Any idea about what can be done to mitigate that?

[sezhilarasan]

Hi,
Any final solution for this, i have just added stacknavigator,Asyncstorage and lineargradient in my project and it showing below error.I am using windows 10.


.

[ShaoGongBra]

it`s me

[scottwio]

To add to this. This change causes some packages to fail in the jest test runs that do not fail in Metro. So rather than getting the same behaviour, we are actually getting different behaviour. I've listed the offending packages below. For any one else experiencing this, if the number of packages affected is small enough, you can mock them out as a workaround.

/node_modules/uuid/dist/esm-browser/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export { default as v1 } from './v1.js';
import { v4 } from 'uuid';

/node_modules/uuid/dist/esm-browser/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export { default as v1 } from './v1.js';
import { createSubscriptionHandshakeLink } from 'aws-appsync-subscription-link';

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.