React-native: Wrong source map is generated

[digeff]

The source maps generated by the react-native packager seem to not be generated properly. We've seen in several projects that the mapping to/from around the React Tags code seems to not be correct.

For example, a user reported this issue: https://github.com/Microsoft/vscode-react-native/issues/206#issuecomment-209109389 in our project, and the root cause of the issue is because the source map file generated by the react-native packager is not correctly mapping to the original source code (The original source code has 76 lines, and the .map files point to line 85 on that file).

[satya164]

Could you provide an example repo where we can reproduce this issue?

[digeff]

Yes, @gilesbradshaw was having this issue on his app, and he told us we can install it by doing:

git clone https://github.com/gilesbradshaw/ua-ql-mobile.git awesome2
cd awesome2
npm i

In https://github.com/Microsoft/vscode-react-native/issues/206#issuecomment-209109389 he describes exactly where to put the breakpoint to reproduce this issue (Which is also where the source maps aren't being correctly generated).

[gilesbradshaw]

Thanks for looking let me know if you cannot replicate with that repo

[janicduplessis]

I also had this issue recently where sources maps were off by ~10-20 lines. It only happened in component files with jsx.

[mroswald]

The more import-statements, jsx-syntax or es6-classes in the module, the more difference is between correct lines and the generated source map.

[digeff]

@satya164 Any updates on this?

[spikebrehm]

I've found a different symptom: the source maps are pointing to the entirely wrong files. Has anyone else experienced this?

[JaxGit]

@spikebrehm we are experiencing the same. At first by combining some of the imports we could get it back to work, however when the project goes, we lost more and more correct file mapping when debugging in Chrome. We have to try debugging in Nuclide to get to the exact breakpoints in exact files in those cases but it's not as powerful as Chrome.

[charpeni]

@facebook-github-bot label Icebox

[charpeni]

Hi there! This issue is being closed because it has been inactive for a while.

But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/wrong-source-map-is-generated

ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.

Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

[charpeni]

@facebook-github-bot close

[facebook-github-bot]

@charpeni tells me to close this issue. If you think it should still be opened let us know why.

[dbeard-groupon]

I also see this occurring. I'm getting completely wrong filenames from sourcemaps.

[vongohren]

I have the problem where iOS works, but android bundlemap is of with 10-20 lines. Is this a common issue around here? I created an issue on it: https://github.com/facebook/react-native

[brunolemos]

I'm having this... rn 0.44

[symptomatik]

I too am having this issue - has anyone else been able to solve it? @brunolemos @vongohren - thanks!

[chefkefu]

Rn 0.48 still has this issue on android release build.

[k0nserv]

I'm seeing something similar, but from my research I don't believe the issue is with the source maps rather the raw stack traces point to the wrong locations in the bundle. As an example if we do throw new Error('test'); at 479:1837 in our bundle the actual location in the stack trace is 479:2150 which has nothing to do with the code path that leads to the error being thrown

EDIT: This is specifically for Android. Testing on iOS both the location in the bundled file and the mapped location with source map is correct.

[k0nserv]

@charpeni can we reopen this?

[charpeni]

@k0nserv Sure.

[charpeni]

@facebook-github-bot reopen

[k0nserv]

I've been doing some more research on this and it seems that it only happens with Android production builds. I've tried with the dev server and a bundle built with --dev true; in both those cases it correctly identifies the source of the exceptions. For Android bundles with --dev false however it's wrong

[facebook-github-bot]

Okay, reopening this issue.

[jamsch]

I was noticing that there's a line difference between 10-16 on the sourcemaps on an Android production app when logging errors to an error tracking service. Certainly is a bit annoying finding the actual lines affected.

Not sure about iOS though.

[HazAT]

Many customers of ours (Sentry) also reported this issue and I can confirm that there definitely is an issue with android source maps.

[RafaelMagalhaesN]

Same issue. Any solution?
React native cli 2.0.1
React native 0.50.3

[windhost]

+1

[youpen]

I come across this issue because an error occurs when init, it does not affect app's feature, but it affects sourcemap. I found this hidden error by 'Pause On Caught Exceptions' of chrome devtool. Hope it helps

[taranda]

Any resolution to this issue?
react-native-cli: 2.0.1
react-native: 0.53.3

[hramos]

The packager has been moved out to its own repo at https://github.com/facebook/metro. This issue has been open for a while and per records seems to still be happening. Please open a new issue at https://github.com/facebook/metro and make sure to provide all the relevant details.

[sospedra]

For future navigators. I moved the issue: https://github.com/facebook/metro/issues/148

[rafeca]

@hramos looks like the root cause of this issue may come from React Native itself, since the sourcemaps generated from metro are correct (more information in https://github.com/facebook/metro/issues/148).

Can you reopen this issue?

[anandprabhu]

@hramos & @rafeca is someone looking into this issue ?

[ozgurchn]

I'm facing the same issue
react-native:0.54

[lavaxun]

I'm facing the same issue.
react-native: 0.51

[avinashwigroup]

Yes... any update on this ?

I'm also having this issue and the wrong stracktrace is showing up when I use BugSnag.

[cpetzel]

Bugsnag does not work properly because of this issue.
react-native: 0.53

[chilons]

This bug happens the same way on both iOS and Android for me, on RN 0.54.2. Why are there so many comments saying this is Android only? Has something changed?

[seanadkinson]

Still doesn't work out of the box with RN 0.55.3, but I may have found a workaround.

By specifying --minify false, it appears the sourcemaps line up correctly. This would explain why dev is working, and not release.

In Android, I use the following in app/build.gradle:

project.ext.react = [
    ...
    extraPackagerArgs: ["--minify", "false"]
]

This causes bugsnag to show me the correct line for javascript errors. Not specifying --minify false, I get wrong line numbers like everyone else.

In my case, the js bundle size went from 2.5mb to 4.1mb. The obvious downside of this is that you'd expect the APK to be larger, but interestingly, I didn't see a noticeable difference in the APK size, since the APK is a zip archive. Also, theoretically it will take longer to initialize the app, but also, I didn't really notice.

I'm now going to see if I need to do the same thing for IOS, and I'll report back here with findings.

[rafeca]

Thanks for the information @seanadkinson! Let me know if you can repro also on iOS

[seanadkinson]

Bugsnag line numbers line up with IOS as well. Just need to specify EXTRA_PACKAGER_ARGS="--minify false" in the Build Phase.

Since the issue is apparently just with the minification, it seems relatively simple to send the bundle through minification manually, and translate the sourcemap accordingly. I don't know if a tool like that exists, but my team will be looking into it shortly I'm sure.

For now, having the sourcemaps correct, at the cost of less than 1mb build size, is a pretty good trade for us.

[anandwahed]

@seanadkinson & @HazAT the above settings works fine with the Sentry SDK also

[pravesh-curefit]

I'm getting the same issue as well. And the approach suggested by @seanadkinson was the only workaround I could find.

[cpetzel]

For those of us who use CodePush, minifying the bundle is a necessity... Not doing so increases the size of the bundle by ~2x, which would slow down required OTA updates via Codepush.

@charpeni @hramos can we get an update on this?

[hramos]

I don't have anything to add - this was not on my radar.

[seanadkinson]

@cpetzel Curious if code-push is configured to use gzip when downloading the bundle, and whether that significantly reduces the 2x size factor for download.

[rafeca]

After investigating much more, I've found that this is actually caused by an issue when generating the source maps from metro. I'm going to land a commit that fixes it

Apologies for the issue 😞

[avinashwigroup]

Is this issue solved now ? Do we need to use the latest react-native version ?

[rafeca]

It's fixed on master, but will not be available until next stable version of react-native (0.56.0)

[anandwahed]

@rafeca with react-native 0.56.0 stable released does this fix added into it. I am not able to see it in the changelog of the 0.56.0 release

[rafeca]

@anandwahed yes, it should have been fixed there 😃

[jshearer]

Just in case anyone comes across this before RN bumps their metro dependency, I finally _finally_ got working line numbers by adding this to my package.json file (make sure you use yarn not NPM)

"resolutions": {
    "react-native/metro": "0.39.1"
}

[jrob-io]

I'm still experiencing this in 0.56.0-rc.2.
node_modules/metro-source-map/package.json has "version": "0.38.1", so this has the changes from @rafeca.

[ospfranco]

I've updated to 0.56, added the false minify flag and also tried to use 0.39.1 resolution method by jsheader, but I still cannot get the source-maps to match.

[fractalwrench]

We've tested this out in an example app that uses React Native 0.56, and it seems as though the original issue can still be reproduced. Here are the steps we followed to observe this behaviour:

1. Build Android app in release mode:

react-native run-android --variant=release

1. Generate sourcemaps:

react-native bundle \
--platform android \
--dev false \
--entry-file index.js \
--bundle-output android-release.bundle \
--sourcemap-output android-release.bundle.map

1. Apply the sourcemaps to an error and inspect the line numbers:

@rafeca please let us know if you require any further information to reproduce this, or whether we're missing some additional step required to get things working - we're more than happy to help out.

[HazAT]

This sadly is still broken 😞
I took the time and put together a "minimal" repro case including tests with our symbolication library symbolic https://github.com/getsentry/symbolic/pull/78

See this repo: https://github.com/HazAT/react-native-source-map with the repro case.
The readme should explain how to run and test is locally.

Hope this helps debugging this issue since we (Sentry) still getting reports that this is broken.

[dawee]

As I understood it in my tests it's not a problem with sourcemap because if you see the line where the error is referenced in index.bundle it's already in the wrong place.

When you look at the symbolicated version using sourcemap, you just have to the original code pointed by index.bundle. So I think index.bundle.map and index.bundle are always coherent together.

Also, there's a similar behaviour when you work with iOS Simulator in dev version. When I tested it with a slow machine I could see dinstinctly a first red error page with the same wrong line number as I can see in sentry. A second after it's updated with the correct line number.

I don't know if any of this can help 😅.

[chrisnovak]

Could we please reopen this? Upgraded to 0.56 and still no help :(

[rafeca]

Hey!

I've been trying to reproduce the issue in my test app but sourcemaps are working fine in that app.

This is the process I follow to verify that they work fine:

 # install the app on the device
$ yarn run prod

Then open the app on the device and write down the line/column numbers of the first trace

# generate the sourcemap file
$ react-native bundle --entry-file index.js --platform ios --dev false --bundle-output main.jsbundle --sourcemap-output main.map # generates the sourcemap

# Symbolicate the line/columns written down in the previous step
yarn run sourcemap main.map 309 494

Check that the correct line/column get printed in the console:

{ source: '.../rn-sample-app/App.js',
  line: 30,
  column: 20,
  name: 'Error' }

Feel free to send a PR to that repo with any change that makes the symbolication fail, this will help me debug the issue.

Additionally, I'm creating end to end tests for sourcemaps in the Metro repository, so anybody experiencing issues with sourcemaps can add a failing test case there to help me debug the issue.

Thanks!

[chrisnovak]

We've been experiencing this issue on Android specifically. I'll try to reproduce on Android in your test app as soon as I have time.

[rafeca]

Ok, from the thread I've seen people complaining for both iOS and Android.

If the issue can only be reproduced in Android, it may be related to the device itself (maybe JSC is reporting the stacktrace position incorrectly).

To verify that, can you please doublecheck if the original line/column reported in the error is correct?

[HazAT]

@rafeca If I try to run your example repo on Android it fails.
I create an release build and put it on a device.

cd android && ./gradlew assembleRelease --stacktrace && \
jarsigner -verbose  -digestalg SHA1 -sigalg MD5withRSA -keystore your-keystore.keystore -storepass ***** app/build/outputs/apk/app-release-unsigned.apk release && \
adb install -r app/build/outputs/apk/app-release-unsigned.apk

react-native bundle --entry-file index.js --platform android --dev false --bundle-output main.jsbundle --sourcemap-output main.map

yarn run sourcemap main.map 306 751

{ source: '/Users/haza/Downloads/rn-test-app-master/App.js',
  line: 38,
  column: 10,
  name: 'createElement' }

tbh I am pretty sure under special circumstances this is also broken on iOS, I am just not sure how to reproduce it there.

[rafeca]

Thanks for the info! 👍 After some fights I've been able to compile the app for Android in release mode and indeed I've been able to reproduce the problem.

If I check line 306, column 751 on the generated production bundle, that position does not correspond to the generated Error position, so the original line/columns that the JS vm are reporting are already wrong:

Actually, the symbolicated line/column (38:10), corresponds to the (wrong) original position, so the issue seems to be coming from JSC and Metro is just doing the right thing.

I recommend creating a different issue for this specific problem (since this issue refers to the sourcemap generation on Metro which was already fixed). Unfortunately I'm not going to be able to assist you with this new one, since this is not my area of expertise... but something I noticed is that this can potentially get fixed once RN upgrades the JSC version for Android.

[dawee]

That's what I meant when I said "index.bundle.map and index.bundle are always coherent together". I really don't think it's a sourcemap issue, the line in the Error doesn't point to the good line in the bundle.

However, try to get the bundle used by you metro server by downloading it from localhost:

curl -L "http://localhost:8081/index.bundle?platform=ios&dev=false&minify=true" > index.ios.bundle.map

(the parameters here are just an example)

You'll see that the bundle you download is never the same you get using react-native bundle and with this one, the error line is correct.

[rafeca]

However, try to get the bundle used by you metro server by downloading it from localhost:
curl -L "http://localhost:8081/index.bundle?platform=ios&dev=false&minify=true" > index.ios.bundle.map

The bundle generated by the devserver should be the same as the one generated by react-native build (using the same dev and minify params on both). The only thing that could change is the module ids (the numbers that are inserted at the end of each compiled file) if you generate several different bundles with the metro server (since these numbers are autoincremental), but they do not affect the sourcemaps.

Do you have any repro steps that make Metro generate different bundles? If so, that's an issue in Metro

[rafeca]

For any future reader landing here because potential sourcemap issues in Metro, I've just created an end to end test that ensures that SourceMaps work fine on a very similar scenario.

[YeatsLu]

@rafeca @HazAT

I recommend creating a different issue for this specific problem (since this issue refers to the sourcemap generation on Metro which was already fixed). Unfortunately I'm not going to be able to assist you with this new one, since this is not my area of expertise... but something I noticed is that this can potentially get fixed once RN upgrades the JSC version for Android.

As you said, I think it is a issue about android jsc, so I open the issue #20628

[HazAT]

The fix that @YeatsLu found works indeed.
Just tried it in my test repo and it works, this it the commit:
https://github.com/HazAT/react-native-source-map/commit/a559cb54482e80b9191b45ee7ea41f247086aa57

So updating JSC for react-native fixes the source map issue for Android.
🎉

[yaronlevi]

Any updates on when this fix will be released?

[ithustle]

@yaronlevi , update to RN 0.57.3, react and react-test-renderer to 16.6.0-alpha.8af6728.

[trickeyd]

0.57.3 and 16.6.0-alpha.8af6728 worked for me! Thanks guys! 🥇

[agrass]

Hello, Is required to update react to fix this?? Any stable version working?

[iadcg]

Tried in RN 0.57.6 and the issues is still there. Im using bugsnag 2.12.6.

[rawrmaan]

I tried RN 0.57.8 with react-native-sentry 0.38.2 and the line numbers are still incorrect.

[zaguiini]

RN 0.57.8, Bugsnag 2.13.1. Still incorrect for Android. iOS is working fine.

[kyle-ssg]

I'm presuming this is related to the original issue, if not then feel free to let me know. Sourcemaps seem to be completely off for me when debugging. Even to the point where inserting debugger; breaks on the wrong file.

Using:

    "react": "16.6.3",
    "react-native": "0.57.8",
    "@babel/core": "^7.0.0",
    "metro-react-native-babel-preset": "0.51.1",

[ithustle]

I recomend running npm update. At least work for me a few days.

[spotsadmin]

This worked for me

1. Close the Metro Bundler terminal window
2. Run watchman watch-del-all && rm -rf $TMPDIR/react-*
3. Run the project react-native run-xx

I am on "react-native": "0.57.7"

[murtraja]

This worked for me (Android)

1. Close the Metro Bundler terminal window
2. react-native start --reset-cache

I am on
"react": "^16.6.0"
"react-native": "0.57.3"
"metro-react-native-babel-preset": "^0.45.0"
"@babel/preset-env": "^7.1.0"

[yurykorzun]

Source maps are off after I updated to 0.59.1 on Android. Works fine for iOS.

[oferRounds]

Experiencing the same issue as @yurykorzun, any workaround?

[oferRounds]

Happens also on 0.59.0

[yurykorzun]

Experiencing the same issue as @yurykorzun, any workaround?

I wish I knew what causes it, so I could try to create fix, but I have no idea. For now, I am debugging only on iOS. I hope there will be a fix soon.

[PedramVeisi]

Source maps are off after I updated to 0.59.1 on Android. Works fine for iOS.

Same here. Started happening after updating to 0.59.1.

[knro]

I am getting this issue too on Android for 0.59.1

"react": "16.8.5",
"react-native": "0.59.1",
"react-test-renderer": "16.8.5",
"metro-react-native-babel-preset": "^0.53.1",

[kelset]

related -> https://github.com/facebook/metro/issues/380