Help debugging: Expected MIME-Type to be 'application/javascript'... but got '(null)'
See original GitHub issueDo 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 😄
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'],
},
};
})();
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:5
Top GitHub Comments
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.
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:
Reproductions steps:
react-native start --reset-cache
Expected: App loads from the Metro server
Actual:
Expected MIME-Type to be 'application/javascript' or 'text/javascript', but got '(null)'
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)