Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source map line number is shifted #48

Open
henrikra opened this issue Feb 20, 2018 · 20 comments
Open

Source map line number is shifted #48

henrikra opened this issue Feb 20, 2018 · 20 comments

Comments

@henrikra
Copy link

This produces at least on Android

I am generating source maps but adding extra packager args in my build.gradle like this

project.ext.react = [
    extraPackagerArgs: isCiBuilding
        ? ["--sourcemap-output", "pathtoMyFolder/index.android.bundle.map"]
        : []
]

After that I just upload that source map file to Bugsnag which is my crashreporter. The crash gives me right file .tsx extension but the line is wrong.

Can you help me to solve this? How to start debugging this? Do I have to pass some arguments to transformer or something?

@ds300
Copy link
Owner

ds300 commented Feb 20, 2018

It should Just Work, so maybe there are some issues.

  1. Are the lines correct at dev time?
  2. Which versions of everything are you running?

@henrikra
Copy link
Author

  1. If I put debug mode to ON when running my app and look sources in Chrome debugger tools yeah they are correct. Even breakpoints work
  • TypeScript 2.7.1
  • react-native-typescript-transformer 1.2.3
  • React native 0.51.0

@ds300
Copy link
Owner

ds300 commented Feb 20, 2018 via email

@henrikra
Copy link
Author

Ahaa! Can you link me info that was related to this fix on RN 52? :D

@ds300
Copy link
Owner

ds300 commented Feb 20, 2018

#11

tldr react-native used to have a spot in the production build pipeline where input source maps were ignored. That issue was resolved as a side effect of a big refactoring effort which landed in 0.52.

@henrikra
Copy link
Author

henrikra commented Feb 21, 2018

I have now upgraded to RN 0.52.2 and still the lines are off.

I am able to reproduce this locally now. Here is my process:

  1. Add some crash to the app that happens on button press
  2. Build app for Android in release mode
  3. Upload source maps to Bugsnag that were just generated by react-native bundle command
  4. Start the app and make it crash
  5. Find new crash on Bugsnag
  6. Notice source maps have been added successfully but the line is wrong ❌

Do you have ideas that I could try? Can I somehow validate the source map file? I have looked into it but it doesn't mean anything to me atm 🙉 How the source map file should look like? How can I validate it is correct?

Btw is this related: facebook/metro#104

@henrikra
Copy link
Author

@ds300 Do you have any ideas?

@ds300
Copy link
Owner

ds300 commented Feb 28, 2018

I can't think of anything that you could do that might solve the problem in 'userland'. If the source maps line up during development but not in production releases, then it's probably the case that metro is still doing some mangling that ignores or misuses input source maps. Last time it was the constant folding and function inlining step. It would take some debugging to figure out where it's happening now. Maybe there's something this package can do to mitigate the issue without touching Metro.

@ankitmittal000
Copy link

Is there any solution for this problem?

@ds300
Copy link
Owner

ds300 commented May 25, 2018

Sorry I haven't looked into this issue

@skellock
Copy link

For the record, I’m having no problems with source maps in production on react native 0.54.

@djereg
Copy link

djereg commented May 25, 2018

Hmm, I have, and waiting patiently for the solution. React 0.55.4

@henrikra
Copy link
Author

Hmm could it be that I am also using ignite-ignore-reactotron plugin in production builds. @skellock

@skellock
Copy link

I try to avoid plugins like that. They rewrite code in a way that is pretty hard to trace. I’m basking in the irony of that advice since I wrote that lib.

You could rule out that by triggering a crash in a file that does have any console.tron statements (or anything else that might get man-handled by it).

I’ll post my relevent configs once I get back to my desk.

Truth be told, they’re pretty vanilla. The only babel shenanigans I’m up to is the one that injects environment vars.

@skellock
Copy link

Config

Here's the relevant snippets from what I'm using.

package.json
{
  "dependencies": {
    "appcenter": "1.4.0",
    "appcenter-crashes": "1.4.0",
    "react-native": "0.54.2",
  },
  "devDependencies": {
    "babel-plugin-transform-inline-environment-variables": "^0.3.0",
    "babel-preset-react-native": "4.0.0",
    "react-native-typescript-transformer": "^1.2.5",
    "tslint": "5.10.0",
    "tslint-config-prettier": "1.12.0",
    "typescript": "2.8.3"
  }
}
tsconfig.json
{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "experimentalDecorators": true,
    "jsx": "react-native",
    "module": "es2015",
    "moduleResolution": "node",
    "noImplicitAny": false,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "allowJs": false,
    "target": "es2015",
    "sourceMap": true,
    "noImplicitReturns": true
  },
  "include": ["src", "test", "storybook"],
  "exclude": ["node_modules"]
}
rn-cli.config.js
module.exports = {
  getTransformModulePath() {
    return require.resolve("react-native-typescript-transformer")
  },
  getSourceExts() {
    return ["ts", "tsx"]
  },
}
babel.rc
{
  "presets": ["react-native"],
  "env": {
    "production": {}
  },
  "plugins": [
    [
      "transform-inline-environment-variables",
      {
        "include": []
      }
    ]
  ]
}

Crash In Action

App Center sample crash (see frame 2) image
Code that crashed image

@ankitmittal000
Copy link

I have put this comment on other issue (#11) but seems that one is closed. Since this one is related so putting it here.

I have tried to test this issue with new version of React Native and I am still able to reproduce it on both android and iOS. I have forked https://github.com/hffmnn/react-native-typescript-starter which is itself a fork of https://github.com/cbrevik/react-native-typescript-starter.

My changes just include changing various versions of dependencies in package.json

So here are the steps

git clone https://github.com/ankitmittal000/react-native-typescript-starter.git
cd react-native-typescript-starter
git checkout --track origin/feature/ts_map_with_new_version
yarn
yarn bundle:ios:release
yarn bundle:android:release

Once you get the bundle generated using above commands, you run the respective android and iOS projects.

For Android project

You will get the following exception which is right

 com.facebook.react.common.JavascriptException: undefined is not an object (evaluating '(void 0).value'), stack:
                                                                       <unknown>@346:460
                                                                       <unknown>@61:2003
                                                                       y@61:1110
                                                                       callTimers@61:3501
                                                                       value@27:4401
                                                                       <unknown>@27:1151
                                                                       value@27:3828
                                                                       value@27:1123

When you try

./symbolicate.js android/main.jsbundle.map 346 460

it will give you

/react_native/react-native-typescript-starter/src/index.tsx:20:10

However this is wrong. The correct result should be

/react_native/react-native-typescript-starter/src/index.tsx:22:10

For iPhone

When you run the app on iPhone you will get the following

typescriptStarter[81082:2398433] *** Terminating app due to uncaught exception 'RCTFatalException: Unhandled JS Exception: undefined is not an object (evaluating '(void 0).value')', reason: 'Unhandled JS Exception: undefined is not an object (evaluating '(void 0).va..., stack:
<unknown>@349:437
y@61:1110
callTimers@61:3501
value@27:4290
<unknown>@27:1040
value@27:3717
value@27:1012

When you try

./symbolicate.js ios/main.jsbundle.map 349 437

you get the following

/react_native/react-native-typescript-starter/src/index.tsx:18:0

However this is wrong. The correct result should be

/react_native/react-native-typescript-starter/src/index.tsx:22:10

Its worth mentioning here that the results generated with bundle using --dev true are correct. The issue reproduces only with --dev false.

From the other comments, it looks like this issue is resolved. Could somebody point to me where am I going wrong?
Thanks for the help.

@henrikra
Copy link
Author

henrikra commented Jul 2, 2018

Still having this problem like @ankitmittal000 What is this ./symbolicate.js located at? With that I can test source maps?

@amol-c
Copy link

amol-c commented Oct 30, 2018

@henrikra Any resolution/workaround on this issue?

@mbret
Copy link

mbret commented Apr 4, 2019

For some reason our app has the same issue. The sourcemaps when using debug remotely on chrome are ok but when debug remotely is turned off they are broken. Updating to 0.59 did not solve it.

the sourcemaps were also broken when using this package for jest and switching to ts-jest fixed that.

@danielmtavares
Copy link

Still having this problem like @ankitmittal000 What is this ./symbolicate.js located at? With that I can test source maps?

I found one in metro-symbolicate. And was able to symbolicate my source maps. With it, you'll be able to verify if the source map is pointing back to the correct lines or not.

$ yarn add -D metro-symbolicate
$ npx metro-symbolicate ./index.map 346 460
../../node_modules/metro/src/lib/polyfills/require.js:412:<global>

Don't mind the output. That's a local test I did that doesn't match the code on previous comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants