Generated source map is broken in React Native 0.59 on Android

Do you want to request a feature or report a bug? It’s most likely a bug

The metro bundler is producing a wrong source map on Android in 0.59.1 and 0.59.0. At least it is consistently happening in my React Native project, but works fine on iOS. I tried to disable JS deltas, it doesn’t help.

It could be related to JSC upgrade, but because I don’t know how source maps are generated and mapped to running javascript on a device, I don’t know exactly what is causing it.

Related issue - https://github.com/facebook/react-native/issues/23955

Last working version

Worked up to version: v0.58.6

Stopped working in version: v0.59.0, still happening in v0.59.1

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

To Reproduce

1. Create a new demo app via react-native init rn059 --version react-native@0.59.1
2. Add a debugger statement in the beginning of the render() method in App.js
3. Launch the app on Android react-native run-android
4. Enable debug mode via the in-app debug menu “Debug JS Remotely”
5. Notice the debugger coming up and stopping somewhere that doesn’t look like the App.js file. In my case, the debugger stops at file:line ReactFabric-prod.js:7030

Link to repo with example code: https://github.com/hypest/rn-059-stacktrace-mess-demo-app

What is the expected behavior?

In step No5 above, the debugger should stop in file App.js, right at the beginning of the render() method where the debugger; statement is.

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.

$ react-native info
info
  React Native Environment Info:
    System:
      OS: macOS 10.14.3
      CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
      Memory: 607.81 MB / 32.00 GB
      Shell: 4.4.19 - /usr/local/bin/bash
    Binaries:
      Node: 8.11.3 - ~/.nvm/versions/node/v8.11.3/bin/node
      Yarn: 1.10.1 - ~/.nvm/versions/node/v8.11.3/bin/yarn
      npm: 6.3.0 - ~/.nvm/versions/node/v8.11.3/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.0, macOS 10.14, tvOS 12.0, watchOS 5.0
      Android SDK:
        API Levels: 23, 26, 27, 28
        Build Tools: 19.1.0, 23.0.1, 26.0.2, 26.0.3, 27.0.3, 28.0.2, 28.0.3
        System Images: android-23 | Google APIs Intel x86 Atom_64, android-26 | Google Play Intel x86 Atom, android-28 | Google Play Intel x86 Atom, android-28 | Google Play Intel x86 Atom_64
    IDEs:
      Xcode: 10.0/10A255 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.8.3 => 16.8.3
      react-native: 0.59.1 => 0.59.1
    npmGlobalPackages:
      create-react-native-app: 1.0.0
      react-native-cli: 2.0.1
      react-native-create-library: 3.1.2
      react-native-git-upgrade: 0.2.7

[motiz88]

With @mjesun’s help I was able to figure out what’s going on here:

1. Metro orders the source map by module ID (as of 5a770dd48a3290b3ad01298a31c2a558823a5117), matching the order in which they appear in plain bundles.
2. In delta bundles, Metro does not put modules in any particular order. The actual order is slightly randomised because of parallelism.
3. The debugger’s delta client (which lives in react-native-cli) concatenates modules in whatever order they come in from Metro.
4. As a side note, turning off delta bundles with a remote debugger attached doesn’t seem to do anything.

As a quick fix, I will send a PR to the CLI repo changing the debugger to always sort the modules before concatenating them. I’ll follow up with React Native to make sure the (separate) delta client implementation there does the same, as this can affect stack traces in dev mode even without the debugger being attached.

More fundamentally, in the long run, the delta bundling protocol should manage source maps as a first-class entity alongside code, instead of assuming that the combined bundle will always match some fixed version of the source map.

[motiz88]

I’m investigating this. Thanks @yurykorzun for the repro code!