expo / sentry-expo

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Adding sentry-expo leads to launch error

remi2257 opened this issue · comments

Summary

When adding expo-sentry to my repo, I have the following fatal error that appears right on start.

com.facebook.react.common .JavascriptException: TypeError: Cannot read property '__extends' of undefined, js engine: hermes, stack: anonymous@1:841281 loadModulelmplementation@1:52808 guardedLoadModule@1:52363 metroRequire@1:51991

I find a "quick fix" in development which is updating tslib to version >= 2.6, but it still breaks on EAS Build.

Also, I have a warning that appears 3 times on start :
warning: The package XX/node_modules/tslib contains an invalid package.json configuration. Consider raising this issue with the package maintainer(s).
Reason: The resolution for "XX/node_modules/tslib" defined in "exports" is XX/node_modules/tslib/tslib.es6.mjs, however this file does not exist. Falling back to file-based resolution.

NB : I had none of these errors/warnings between adding expo-sentry

full_error

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?

Android, iOS

SDK Version (managed workflow only)

49

Environment

expo-env-info 1.0.5 environment info:
System:
OS: Linux 5.19 Ubuntu 22.04.2 LTS 22.04.2 LTS (Jammy Jellyfish)
Shell: 5.8.1 - /usr/bin/zsh
Binaries:
Node: 18.16.0 - ~/.volta/tools/image/node/18.16.0/bin/node
Yarn: 1.22.19 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
npm: 9.5.1 - ~/.volta/tools/image/node/18.16.0/bin/npm
SDKs:
Android SDK:
API Levels: 30, 31, 33
Build Tools: 30.0.3, 31.0.0, 33.0.0
System Images: android-33 | Google APIs Intel x86 Atom_64
IDEs:
Android Studio: AI-222.4459.24.2221.10121639
npmPackages:
@expo/metro-config: 0.10.7 => 0.10.7
babel-preset-expo: 9.5.1 => 9.5.1
expo: 49.0.6 => 49.0.6
metro: 0.76.7 => 0.76.7
react: 18.2.0 => 18.2.0
react-dom: 18.2.0 => 18.2.0
react-native: 0.72.3 => 0.72.3
react-native-web: 0.19.7 => 0.19.7
Expo Workflow: managed

Reproducible demo or steps to reproduce from a blank project

  • create a Nx 16.6.0 workspace
  • Add an Expo application with SDK 49 + working with the dev client
  • Add the package sentry/expo
  • Errors/Warnings appears on start

Well, I tried to reproduce my quick fix which consist in changing the tslib version, but I cannot make it work anymore :')

The error in development is the following

 ERROR  TypeError: Cannot read property '__extends' of undefined, js engine: hermes
 ERROR  Invariant Violation: "main" has not been registered. This can happen if:
* Metro (the local dev server) is run from the wrong folder. Check if Metro is running, stop it and restart it in the current project.
* A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called., js engine: hermes
commented

Running into a similar issue. Not an error, just bundler warnings.

warning: The package <...>/node_modules/tslib contains an invalid package.json configuration. Consider raising this issue with the package maintainer(s).

Appears to be rare and Metro-specific. Searching for "contains an invalid package.json configuration" returns only one hit, this page.

I'm getting the same warnings but with different packages:

warning: The package C:\hobby\node_modules\js-base64 contains an invalid package.json configuration. Consider raising this issue with the package maintainer(s).
Reason: The resolution for "C:\hobby\node_modules\js-base64" defined in "exports" is C:\hobby\node_modules\js-base64\base64.mjs, however this file does not exist. Falling back to file-based resolution.

warning: The package C:\hobby\apps\mobile\node_modules\react-hook-form contains an invalid package.json configuration. Consider raising this issue with the package maintainer(s).
Reason: The resolution for "C:\hobby\apps\mobile\node_modules\react-hook-form" defined in "exports" is C:\hobby\apps\mobile\node_modules\react-hook-form\dist\index.esm.mjs, however this file does not exist. Falling back to file-based resolution.

Not sure if is related to sentry only.
I'm using nx monorepo.

Not sure if is related to sentry only. I'm using nx monorepo.

I'm also using NX monorepo !
I never had the problem before installing sentry ;)

Same error here, also using NX monorepo with expo plugin.
I managed to fix the issue with @sentry/react-native:

// index.js
import { registerRootComponent } from 'expo';
import * as Sentry from '@sentry/react-native';

import App from './src/app/App';

Sentry.init({
  dsn: 'YOUR DNS',
  tracesSampleRate: 1.0,
});
registerRootComponent(App);
commented

I have this error

warning: The package D:\nx-workspace\node_modules\tslib contains an invalid package.json configuration. Consider raising this issue with the package maintainer(s).
Reason: The resolution for "D:\nx-workspace\node_modules\tslib" defined in "exports" is D:\nx-workspace\node_modules\tslib\tslib.es6.mjs, however this file does not exist. Falling back to file-based resolution.

What should I do ?! I am using expo in nx monorepo

This was fixed downstream in sentry-javascript. getsentry/sentry-javascript#8255

Can you upgrade to sentry-react-native https://github.com/getsentry/sentry-react-native/releases/tag/5.7.0 or newer?

Still getting this warning. Perhaps somebody knows any new ways to fix it or work around it?

I was looking at some options to suppress or disable this warning - but no luck so far. Would be very glad to hear that someone fixed this in their project.

@krystofwoldrich I temporarily fixed it by adding config.resolver.unstable_conditionNames = ["require", "default"] to the metro.config.js. I'm pretty sure this can cause some other issues in the future, but it worked, and nothing has broken so far.

About your question, I have a bunch of other packages - so I can't say too sure that updating to the latest sentry version fixed it. As my warning originated from tslib itself and they haven't fixed it yet in the v2.6.2.

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.

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.