-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
[iOS 16.4 + JSC]: Unable to resolve [package] from [dependency/file/path] #22008
Comments
After going through and manually updating the import paths to add a
|
hey @billyjacoby - this reproducible example isn't quite minimal enough for us, there are too many libraries involved here that are likely the cause of the issue. are you able to isolate this to a specific root cause, ideally with no external libraries, or if using an external library, a very small one that is open source on github? |
This is probably caused by the recent problem in iOS 16.4: facebook/react-native#36794 @brentvatne You may want to consider to reopen the issue as it's a valid problem confirmed by RN upstream. Expo may want to have its own suggested workaround. |
thanks @IlyaSemenov! the workaround suggested by @robhogan in facebook/react-native#36794 (comment) will work, with a slight tweak to extend the default expo metro config: const { getDefaultConfig } = require('expo/metro-config');
const config = getDefaultConfig(__dirname);
config.server.rewriteRequestUrl = (url) => {
if (!url.endsWith('.bundle')) {
return url;
}
// https://github.com/facebook/react-native/issues/36794
// JavaScriptCore strips query strings, so try to re-add them with a best guess.
return url + '?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true';
};
module.exports = config; alternatively, switching to hermes will resolve this and is a good choice! it is the default in sdk 48 and we recommend it. |
I added that code in my expo metro config but I still get the same error. Fair enough, the app takes longer before crashing, but it still does. Here is my
|
In the repo I originally linked I included a branch that is using the 48 version of Expo (hermes support) and get all the same errors: |
Just started running into this issue as well. Is there a fix in newer versions coming? |
@mypalvikram - the react-native team is working on a fix: facebook/react-native#36794 (comment) however, i personally would recommend that you use this as one more piece of motivation to switch from jsc to hermes. that will also resolve the issue and bring many other benefits, such as an improved debugging experience |
I'm actually using Expo version 48 and Hermes is default but, I still run into this. This makes me think that there's potentially another package causing this issue in my case. Thanks for the feedback, I'll dig a little more. |
I'm also using Hermes and running into the same issues but only with Expo and not in a bare React native project |
Summary: The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Differential Revision: D45983876 fbshipit-source-id: cbf749bae0256bc981588fa2b9e7b0d60eba7461
…ook#989) Summary: Pull Request resolved: facebook#989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: b13c712521f7a3b6716c14d392cb3a057ede5936
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Summary: Pull Request resolved: #989 The remaining Metro part of the implementation of react-native-community/discussions-and-proposals#646, to fix (along with an RN change): - facebook/react-native#36794 and - expo/expo#22008 This ensures that Metro always and consistently emits "JSC-safe" (i.e., `//&` query-delimited) URLs where they are used as a "source URL" for evaluated JS. This includes: - `sourceURL` within the JSON HMR payload (`HmrModule`) - `//# sourceURL` comments within the body of a base or HMR bundle - The new `Content-Location` header delivered in response to an HTTP bundle request. Clients will be expected to use these as source URL arguments to JS engines, in preference to the URL on which they might have connected/requested the bundle originally. ``` * **[Fix]**: Emit source URLs in a format that will not be stripped by JavaScriptCore ``` Reviewed By: GijsWeterings Differential Revision: D45983876 fbshipit-source-id: 3e7f0118091424b9c1b1d40e4eb7baeb5be1f48f
Upgraded to a patched version of RN (0.69.12, in my case); built a new custom dev client. Still seeing the same errors:
Implementing the mod to metro.config.js (facebook/react-native#36794 (comment)) seems to work as a workaround, though. |
any fix? it's been 4 months.. |
--Edit -> FIXED for my own project by upgrading to expo 49. Still not sure what the issue was. It fixed the constants issue too. I don't remember having this issue until as of late. I can't seem to figure out the cause of this too :(. Using expo 48, randomly throws this error. Possibly from libraries installed with expo is my guess? Also I keep getting this deprecated warning about Constants.platform.ios even though I haven't used that command anywhere. -- My issue was somehow fixed once I upgraded to EXPO 49. Not sure what was the cause, if you can upgrade to the latest, try it out. |
still showing errors |
switch my config to use hermes https://docs.expo.dev/guides/using-hermes/ fixed me this should be mentioned in |
MAN THAT WAS HARD! had to - downgrade react-native to 0.71 - upgrade kotlin to 1.8 - downgrade gradle to 7.6 - change the location of @react-native/gradle-plugin to react-native-gradle-plugin - setup the expo config to use the hermes compiler (not mention in doc :/ ) facebook/react-native#38179 expo/expo#22008
* bring over stuff that looks good from standard native modules attempt #10 * expo config setup init MAN THAT WAS HARD! had to - downgrade react-native to 0.71 - upgrade kotlin to 1.8 - downgrade gradle to 7.6 - change the location of @react-native/gradle-plugin to react-native-gradle-plugin - setup the expo config to use the hermes compiler (not mention in doc :/ ) facebook/react-native#38179 expo/expo#22008 * missed a spot * got everything running with no errors ran into this ugly one called java.lang.IllegalStateException: Current Activity is of incorrect class, expected AppCompatActivity, received ui.MyReactActivity hard to debug for real for real. ended up looking into expo docs that said they are getting rid of the bare instructions and then expo/expo#18022 then that had me be like where is that erorr even from... which lead me to git blame packages/expo-modules-core/android/src/main/java/expo/modules/kotlin/AppContext.kt which lead me to expo/expo#19573 which lead me to s/Activity/AppCompatActivity/g in android/app/src/main/java/com/github/quarck/calnotify/ui/MyReactActivity.kt * fix: forgot to switch to matching gradle version for android build plugin * def don't need react native picker hope we don't need expo install modules either * kinda crazy but got a (mostly) WORKING NATIVE MODULE! in modules/my-module/android/src/main/java/expo/modules/mymodule/MyModule.kt Constants, Events, and AsyncFunction work beautifully! View seems to work but I don't really understand it weirdly Function DOES NOT WORK AT ALL!!! it just says is not a function and since it seemed like the easiest thing and was what I looked at first it made me thing everything else was broken too :/ lost A LOT of time to that * Logcat instead of println and hello on button press * document why chrome debugging doesn't work as expected by default to save myself time in the future * debugging with vscode works!!!! unfortunately debugging syncronous native modules in it does not :/ * more docs on debugging * react-native-devsettings because why not * flipper setup again because why not? * drop a android studio thing that didn't work * fix readme * drop a dependency we dont need that had a peer dependency that broke shit expo-module-scripts 3.1.0 depends on @expo/config 7.5 which breaks shit * Revert "flipper setup again because why not?" turns out it breaks build. like flipper but not worth build break This reverts commit 8612ff3. * do still want to set entryFile though
This issue is stale because it has been open for 90 days with no activity. If there is no activity in the next 7 days, the issue will be closed. |
This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem. |
Summary
When trying to build, I get a number of issues about being unable to resolve files from dependencies of my project. For example:
Unable to resolve "@ledgerhq/devices/hid-framing" from "node_modules/@ledgerhq/hw-transport-webhid/lib/TransportWebHID.js"
"@ledgerhq/devices/hid-framing" from "node_modules/@ledgerhq/hw-transport-webusb/lib/TransportWebUSB.js"
Unable to resolve "@react-native-async-storage/async-storage" from "node_modules/@walletconnect/keyvaluestorage/dist/cjs/react-native/index.js"
Replacing these imports with
undefined
for testing causes errors like the following untilnode_modules
is cleaned and dependencies are reinstalledWhat platform(s) does this occur on?
No response
SDK Version
47.0.12
Environment
Minimal reproducible example
Repo can be found here:
https://github.com/billyjacoby/expo-unable-to-resolve
There's a branch using the most up to date Expo-CLI there as well
The text was updated successfully, but these errors were encountered: