Were you able to get your implementation working with web?
I’m using Expo SDK 35, Sentry Expo 2.0.1 and getting the following like you did.
Module parse failed: Unexpected token (25:12)
You may need an appropriate loader to handle this file type.
|
| class ExpoIntegration {
> static id = 'ExpoIntegration';
| name = ExpoIntegration.id;
1 Like
I was not able to get it to work. I’m still thinking that it’s something Babel-related that might fix it, but after some trial and error I made no progress and had to shelve it.
Thanks for getting back to me. @charliecruzan Are you able to shed any light on getting this to work with Web? Should I start a new topic maybe?
sentry-expo doesn’t support web just yet, it is something we want to get to eventually. In the meantime, we’re always open to PRs to the repo to get it working 
Quest accepted. If I get it working, I’ll submit a PR!!
2 Likes
That’d be awesome! Happy to help and collab on it, so keep me updated and feel free to open a WIP PR
So it seems like it’s just a babel/webpack issue. static id = 'ExpoIntegration'; Throws an error because it’s a class property. I added
['@babel/plugin-proposal-class-properties', { loose: true }],
to my babel.config.js file, but it still throws the error. Do you know if I also have to add anything to webpack.config.js to respect the addition to the babel config?
FYI: As a workaround until we come up with a consolidated native+web sentry-expo, I’m using .native and .web config files to import and initialize either sentry-expo for the native packages or “@sentry/browser” for the web build of my app. In addition to giving me working error tracking on the web, I can also track git commits with my releases (something I don’t get from sentry-expo).
@charliecruzan @apoyando @craig-venturetec
Has anyone gotten Expo web to compile while having Sentry installed? I’m happy to not use Sentry on the web for now, but I can’t even get my web project to compile (“You may need an appropriate loader…” error above) because Sentry is installed ("sentry-expo@2.0.1).
@apoyando Could you explain your solution further if it does this? Thanks
More generally, it seems like this happens quite frequently. Another package that’s cause it for me currently is rn-sliding-up-panel. It would be nice if there were a way to make all these issues go away. I also tried getting “[‘@babel/plugin-proposal-class-properties’, { loose: true }],” but couldn’t get it to work.
EDIT: Downgrading to Sentry 1.13.0 seems to fix the issue for now.
@vjsingh, here’s a simplified version of what I did to sidestep the sentry-expo web incompatibility:
- I created two files: sentry.native.js and sentry.web.js
- In sentry.native.js, I import and initialize sentry from ‘sentry-expo’ just as the Expo docs specify, then export the Sentry object.
- In sentry.web.js, I import and initialize sentry from ‘@sentry/browser’ (which I installed) as specified in the sentry standard JS documentation (it’s very similar, but there’s no ‘enableInExpoDevelopment’). I also export the Sentry object from this file.
- In my App.js, I import Sentry from ‘./sentry’. Now when I build the native files, Expo will import from ‘sentry.native.js’. When I build the web files, I’ll be importing from ‘sentry.web.js’.
That’s hopefully enough just to get things working. In my case, I added an error boundary and am also reporting separate releases to Sentry for my web app at publish time.
2 Likes
@apoyando Thanks that’s a good explanation. And a clever trick about the “.native.js” and “.web.js” I didn’t realize Expo would do that automatically.
I’m a little confused though since I’m not even attempting to use Sentry in my web project at all. I believe it doesn’t require Sentry in any way, so I’m not sure why it’s causing the compile time error. If it’s working for you then perhaps I set up my project in the wrong way somehow.
@vjsingh I think if you’re importing and initializing Sentry from ‘sentry-expo’ anywhere in your app, you’re going to run into a problem when doing the web build. Are you doing it in App.js?
@apoyando Thanks for your help I’ve been struggling with this.
You may be right. It looks like my App.js imports both my NativeApp and my WebApp and then conditionally exports the right one based on what Platform.OS says. Is there a way to have two different entry points?
I also have this strange line in it. Not sure why… might be related?
export * from './src/src/App';
(which is my native app)
Full code:
import NativeApp from './src/src/App';
import WebApp from './src/src/web/App';
import { Platform } from 'react-native';
let app = NativeApp as any;
if (Platform.OS === 'web') {
app = WebApp;
}
export default app;
export * from './src/src/App';
@vjsingh If you’re always exporting * from your native app entry, you’re always going to get your Sentry initialization from there.
If your web app actually needs exports from what is now your native app entry, then you might want to rethink the way you’ve structured your project. If not, then the “export *” is at best unnecessary.
Again, the web vs native logic you’re using could be replaced by using platform-specific files. You could simply import app from './App' in the file you quote above, and then create App.native.js and App.web.js files to import the right entries from the right directories.
1 Like
@apoyando Thanks so much! This is actually a huge help for us. I’ve wasted countless hours dealing with issues where my web project wouldn’t compile because of an import that was only in my native code.
I won’t have time to look at this until next week but it looks like it should work.
@charliecruzan I can’t find any mention of the app.native.js and app.web.js files in the Expo documentation. Did I miss it, or if not would it be worth adding?
@vjsingh This is the documentation you need: https://docs.expo.io/versions/v35.0.0/react-native/platform-specific-code/
2 Likes
@apoyando Thanks for the info - I set up my entry points in the way you described, and now don’t get compile time issues for unused files.
The only remaining issue is that Typescript doesn’t seem to understand the “.web.tsx” and “.native.tsx” extensions.
Is there a way around this? Found these two related issues:
https://github.com/Microsoft/TypeScript/issues/21926
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.