Help debugging: Expected MIME-Type to be 'application/javascript'... but got '(null)'

[lindboe]

Do you want to request a feature or report a bug?

Report a bug and request help debugging.

What is the current behavior?

When running a React Native 0.64 app with Hermes on a physical iOS device, I eventually hit an error while trying to load the app JS, which says Expected MIME-Type to be 'application/javascript' or 'text/javascript', but got '(null)'.

Clearing out node_modules and running with --reset-cache does fix the issue (edit: just --reset-cache is sufficient, no need to delete node_modules), but it doesn't take long to occur again. It's inconsistent, but I've even seen it fail on the first refresh after a reset-cache launch.

I haven't seen this on an Android device, or on an iOS simulator. Android continues to be able to load JS from metro after this happens.

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.

I unfortunately have no idea how to reproduce this. If anyone could provide debugging suggestions, I'm happy to run them.

What is the expected behavior?

The javascript is served so that the app can load it :smile:

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

Metro version: 0.64.0 Node version: v14.16.0 yarn version: 1.22.10

metro.config.js:

const {getDefaultConfig} = require('metro-config');

module.exports = (async () => {
  const {
    resolver: {sourceExts, assetExts},
  } = await getDefaultConfig();
  return {
    transformer: {
      getTransformOptions: async () => ({
        transform: {
          experimentalImportSupport: false,
          inlineRequires: true,
        },
      }),
      babelTransformerPath: require.resolve('react-native-svg-transformer'),
    },
    resolver: {
      assetExts: assetExts.filter(ext => ext !== 'svg'),
      sourceExts: [...sourceExts, 'svg'],
    },
  };
})();

[dkarter]

Glad to see we are not alone!

We have had the same issue ever since upgrading to React Native 0.64.2 (from 0.61). It only happens when running on physical devices, not on simulators which is why I think it wasn't caught.

My team is integrating an iPad app with a BT peripheral which is why we have to run our app on a physical device for our daily work.

We are not using Hermes so maybe that variable can be eliminated.

Metro version: 0.64.0 Node version: v14.15.4 Yarn version: 1.22.5

metro config:

module.exports = {
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true
      }
    })
  }
};

Reproductions steps:

• Run the metro server react-native start --reset-cache
• Run the app on iOS (everything should load fine)
• Then force close the app on iOS and re-open it

Expected: App loads from the Metro server

Actual:

• Seeing an error Expected MIME-Type to be 'application/javascript' or 'text/javascript', but got '(null)'
• Clicking "Reload JS" does not work.
• Metro shows this instead of a progress bar:

The only workaround we found was to restart the metro server every time we restart the app which is not ideal... (but no need to delete the node_modules folder and reinstall in our case)

[lindboe]

I was just now able to reproduce this with a new RN 0.64 project made with react-native init and running on device (iPhone 8+, react-native info output below)

I'm going to also look at filing a react-native (CLI?) issue to hopefully get more eyes on this.

Environment info:

➜  TestProject yarn react-native info
yarn run v1.22.10
$ /Users/lizzilindboe/dev/TestProject/node_modules/.bin/react-native info
info Fetching system and libraries information...
System:
    OS: macOS 11.4
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 693.71 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.0 - /var/folders/t3/qdr7x1_x6kq3zhmlmd9_1kt80000gq/T/yarn--1626373443556-0.32661718408266616/node
    Yarn: 1.22.10 - /var/folders/t3/qdr7x1_x6kq3zhmlmd9_1kt80000gq/T/yarn--1626373443556-0.32661718408266616/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm
    Watchman: 2021.06.07.00 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.1 - /Users/lizzilindboe/.rbenv/shims/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
    Android SDK:
      API Levels: 23, 28, 29, 30
      Build Tools: 29.0.2, 30.0.2, 30.0.3
      System Images: android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.2 AI-202.7660.26.42.7351085
    Xcode: 12.5.1/12E507 - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_292 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: 0.64.2 => 0.64.2
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
✨  Done in 3.80s.

[YadongChen]

any update pls? have been following for several days

[jimmyfortinx]

We have faced the same issue and lost a lot of time to figure out you only need to update your Mac to at least version 11.5.1 (which is the oldest version we were able to make RN 0.64 work).

On the older version (11.3.1, for us) the response given by Metro to the native application is malformed because chunks are in the wrong order. We don't know why it's doing this on an older version of Mac OS, but at least we now all have a workaround.

For those who want to investigate the issue, please continue to read. Once the app is installed on your device and you can reproduce the crash by tapping R in the terminal.

After the app crashed, you can easily see the issue by querying http://<your metro server ip address>:<metro port>/container_autogenerated/index.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=<app bundle id> through postman and add the expected headers Now Postman is going to tell you the response is malformed.

At this point, we used curl to get the real response and saw the response was completely broken, the header was at line 2041 instead of the first line and on the first line, we had a piece of JS code.

[BM-laoli]

Hello brothers, my computer system MAC Version 11.4 also encountered this problem, now it is normal after upgrading to 11.5. My other MAC, Version 10.15.7, didn't find this problem