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

Xcode 14.3 - Error: Unable to resolve module ./Libraries/Components/DatePicker/DatePickerIOS #36794

Closed
mjmasn opened this issue Apr 4, 2023 · 112 comments
Labels
Needs: Attention Issues where the author has responded to feedback. Platform: iOS iOS applications. Resolution: Fixed A PR that fixes this issue has been merged. Tech: Bundler 📦 This issue is related to the bundler (Metro, Haul, etc) used.

Comments

@mjmasn
Copy link
Contributor

mjmasn commented Apr 4, 2023

This issue is now fixed, for more details check out this comment.

Description

Since upgrading to Xcode 14.3 and working around the other new issues i.e. the codegen ios target version issue, there is still a further issue with metro. Getting a lot of these type of errors. It seems to be every time metro logs a log line from iOS (not Android), it then logs the below message as well (full paths redacted).

This seems to cause a memory leak as well, with the metro node process eventually crashing when > 4GB RAM is used.

The error message is interesting for many reasons.

  1. Firstly it seems to be trying to resolve a flow type import.
  2. Secondly the path does exist, but metro is not checking the platform-specific path i.e. DatePickerIOS.ios.js.
  3. Thirdly we don't even use DatePickerIOS in the app.

None of these files exist:
  * node_modules/react-native/Libraries/Components/DatePicker/DatePickerIOS(.native|.native.js|.js|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.engine.js|.engine.js)
  * node_modules/react-native/Libraries/Components/DatePicker/DatePickerIOS/index(.native|.native.js|.js|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.engine.js|.engine.js)
  15 | import typeof ActivityIndicator from './Libraries/Components/ActivityIndicator/ActivityIndicator';
  16 | import typeof Button from './Libraries/Components/Button';
> 17 | import typeof DatePickerIOS from './Libraries/Components/DatePicker/DatePickerIOS';
     |                                   ^
  18 | import typeof DrawerLayoutAndroid from './Libraries/Components/DrawerAndroid/DrawerLayoutAndroid';
  19 | import typeof FlatList from './Libraries/Lists/FlatList';
  20 | import typeof Image from './Libraries/Image/Image';
    at ModuleResolver.resolveDependency (node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:107:15)
    at DependencyGraph.resolveDependency (node_modules/metro/src/node-haste/DependencyGraph.js:288:43)
    at Object.resolve (node_modules/metro/src/lib/transformHelpers.js:129:24)
    at resolve (node_modules/metro/src/DeltaBundler/traverseDependencies.js:396:33)
    at node_modules/metro/src/DeltaBundler/traverseDependencies.js:412:26
    at Array.reduce (<anonymous>)
    at resolveDependencies (node_modules/metro/src/DeltaBundler/traverseDependencies.js:411:33)
    at processModule (node_modules/metro/src/DeltaBundler/traverseDependencies.js:140:31)
    at async addDependency (node_modules/metro/src/DeltaBundler/traverseDependencies.js:230:18)
    at async Promise.all (index 9)

NOTE that this is not the codegen ios target version issue, I've already worked around that using the patch which has been released as 0.70.8

React Native Version

0.70.6

Output of npx react-native info

System:
    OS: macOS 13.3
    CPU: (8) arm64 Apple M1 Pro
    Memory: 1.78 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.10.0 - ~/.nvm/versions/node/v16.10.0/bin/node
    Yarn: 1.22.19 - ~/redacted/node_modules/.bin/yarn
    npm: 8.0.0 - ~/redacted/node_modules/.bin/npm
    Watchman: 2023.02.27.00 - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /redacted/.rbenv/shims/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK: Not Found
  IDEs:
    Android Studio: 2021.3 AI-213.7172.25.2113.9014738
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 17.0.4.1 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: 0.67.1 => 0.67.1
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

Running a previously working app on Xcode 14.3 / iOS simulator with rosetta

Snack, code example, screenshot, or link to a repository

Can't provide one at this stage

@github-actions
Copy link

github-actions bot commented Apr 4, 2023

⚠️ Newer Version of React Native is Available!
ℹ️ You are on a supported minor version, but it looks like there's a newer patch available. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

@dmontag23

This comment was marked as duplicate.

@cchampou

This comment was marked as duplicate.

@focux

This comment was marked as duplicate.

@nvictor-acv
Copy link

nvictor-acv commented Apr 4, 2023

Started going down that rabbit hole too

Error: Unable to resolve module ./Libraries/Components/DatePicker/DatePickerIOS from `/xxx/node_modules/react-native/index.js: 

None of these files exist:
  * node_modules/react-native/Libraries/Components/DatePicker/DatePickerIOS(.native|.native.js|.js|.native.jsx|.jsx|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.svg|.svg)
  * node_modules/react-native/Libraries/Components/DatePicker/DatePickerIOS/index(.native|.native.js|.js|.native.jsx|.jsx|.native.json|.json|.native.ts|.ts|.native.tsx|.tsx|.native.svg|.svg)
  15 | import typeof ActivityIndicator from './Libraries/Components/ActivityIndicator/ActivityIndicator';
  16 | import typeof Button from './Libraries/Components/Button';
> 17 | import typeof DatePickerIOS from './Libraries/Components/DatePicker/DatePickerIOS';
     |                                   ^
  18 | import typeof DrawerLayoutAndroid from './Libraries/Components/DrawerAndroid/DrawerLayoutAndroid';
  19 | import typeof FlatList from './Libraries/Lists/FlatList';
  20 | import typeof Image from './Libraries/Image/Image';

Xcode v14.3
React Native 0.70.6
Build Target iOS 14.0

Architecture: Apple Silicon (M1 Max)

Had to manually change the iOS Deployment Target of Pods > React-Codegen to iOS 12.4 or otherwise it won't build.

Steps to reproduce:

  • Build and run with the aforementioned configuration.
  • Navigate around your app.
  • Metro eventually produces a memory leak on node (I'm using nvm)
    image

@kelset kelset added the Needs: Repro This issue could be improved with a clear list of steps to reproduce the issue. label Apr 4, 2023
@github-actions
Copy link

github-actions bot commented Apr 4, 2023

⚠️ Missing Reproducible Example
ℹ️ It looks like your issue is missing a reproducible example. Please provide a Snack or a repository that demonstrates the issue you are reporting in a minimal, complete, and reproducible manner.

@cristianmacedo

This comment was marked as duplicate.

@avdhhh

This comment was marked as duplicate.

@abanik0831usc
Copy link

same issue

1 similar comment
@epweil
Copy link

epweil commented Apr 4, 2023

same issue

@epweil

This comment was marked as resolved.

@daviddalmaso
Copy link

Same issue

1 similar comment
@cankilinc
Copy link

Same issue

@s-kuniyoshi

This comment was marked as duplicate.

@usescrt

This comment was marked as duplicate.

@dsshard

This comment was marked as duplicate.

@cankilinc

This comment was marked as duplicate.

@AND-GORNIY

This comment was marked as duplicate.

@Tibze

This comment was marked as duplicate.

@hcbylmz

This comment was marked as duplicate.

@AsteriskZuo
Copy link

update: we just released 0.71.11 that contains the same fix we've put in 72 RC5, please check it out. Patches for 0.70 and 0.69 will come out in the next few weeks.

thanks, it works now, but now i am getting one more issue here in IOS 16.4 Simulator.

Error: Unable to resolve module ./Libraries/Components/DrawerAndroid/DrawerLayoutAndroid from /Volumes/Work/Projects/aolf-teacher-mobile-app-expo-47/node_modules/react-native/index.js:

None of these files exist:

  • node_modules/react-native/Libraries/Components/DrawerAndroid/DrawerLayoutAndroid(.native|.native.ts|.ts|.native.tsx|.tsx|.native.js|.js|.native.jsx|.jsx|.native.json|.json)
  • node_modules/react-native/Libraries/Components/DrawerAndroid/DrawerLayoutAndroid/index(.native|.native.ts|.ts|.native.tsx|.tsx|.native.js|.js|.native.jsx|.jsx|.native.json|.json)
    15 | import typeof ActivityIndicator from './Libraries/Components/ActivityIndicator/ActivityIndicator';
    16 | import typeof Button from './Libraries/Components/Button';

17 | import typeof DrawerLayoutAndroid from './Libraries/Components/DrawerAndroid/DrawerLayoutAndroid';
| ^
18 | import typeof FlatList from './Libraries/Lists/FlatList';
19 | import typeof Image from './Libraries/Image/Image';
20 | import typeof ImageBackground from './Libraries/Image/ImageBackground';

Also attached the path screenshot it is looking for. Am i doing something wrong here?

Screenshot 2023-06-15 at 8 50 31 AM

In version 0.71.8, the problem is the same as yours, after upgrading to version 0.71.11, the problem does not occur, and there are no more problems you mentioned. You can try clearing the cache.

douglowder pushed a commit to react-native-tvos/react-native-tvos that referenced this issue Jun 19, 2023
…7501)

Summary:
Pull Request resolved: facebook/react-native#37501

This is the iOS side of the fix for facebook/react-native#36794.

That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).

Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](react-native-community/discussions-and-proposals#646) to pass to the JS engine, even where the request URL isn't JSC-safe.

We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).

For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.

For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.

Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL

Reviewed By: huntie

Differential Revision: D45950661

fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
@dennisdelima21pe
Copy link

When updating to version 0.71.11 the following error appears

Error: Unable to resolve module ./Libraries/Components/DrawerAndroid/DrawerLayoutAndroid from /Volumes/Work/Projects/aolf-teacher-mobile-app-expo-47/node_modules/react-native/index.js:

None of these files exist:

node_modules/react-native/Libraries/Components/DrawerAndroid/DrawerLayoutAndroid(.native|.native.ts|.ts|.native.tsx|.tsx|.native.js|.js|.native.jsx|.jsx|.native.json|.json)
node_modules/react-native/Libraries/Components/DrawerAndroid/DrawerLayoutAndroid/index(.native|.native.ts|.ts|.native.tsx|.tsx|.native.js|.js|.native.jsx|.jsx|.native.json|.json)
15 | import typeof ActivityIndicator from './Libraries/Components/ActivityIndicator/ActivityIndicator';
16 | import typeof Button from './Libraries/Components/Button

@GiomScript
Copy link

I have the same issue and I tried all the latest versions since 0.69.0. since these issues popped up I get this error too: ERROR Error uploading an image to Firebase Storage: [TypeError: undefined is not an object (evaluating 'ref._location')], when I try to upload the image to Firebase storage. I hope these are all related issues and fix is coming up soon.

@nagesher
Copy link

i"m also having the same issue

@ikeller96
Copy link

I'm also getting the same issue now. Expo version 47.0.9 and React Native Version 0.70.8.

@JustinShuttleworth
Copy link

same issue

@AamenaSaiyed
Copy link

I'm also getting the same issue now. Expo version 47.0.9 and React Native Version 0.70.8.

Me too have same issue even i cant change minimum target version to 12 cause my minimum supported ios version is 13 due to expo sdk v47.0

@robhogan Any help will be appriciated

@Spxc
Copy link

Spxc commented Jun 25, 2023

  • leak on node (I'm u

This seems to be a temporary workaround as you've written, and eventually Metro crashes due to a memory leak. Anyone know what's causing the leaks? Randomly started happening after XCode 14.3

@robhogan
Copy link
Contributor

A reminder that this fix is only included with RN 0.72.0 and RN 0.71.11. Fixes for 0.70.x and 0.69.x are coming but are not yet available.

If you're experiencing this issue on RN 0.72.0 or 0.71.11, please let us know about your setup in as much detail as you can, ideally following the new issue guidelines. If you're not on one of those two versions the error is expected for now - please be patient and use the workaround steps linked in the OP in the meantime. Thanks!

@robhogan
Copy link
Contributor

  • leak on node (I'm u

This seems to be a temporary workaround as you've written, and eventually Metro crashes due to a memory leak. Anyone know what's causing the leaks? Randomly started happening after XCode 14.3

This is a good question but I'm 90% certain there's no leak as such - rather a loop between Metro and client where the failure to symbolicate causes a reload, which then raises an error that fails to symbolicate, etc. In some circumstances that means Metro is dealing with multiple parallel bundling and symbolication requests and simply runs out of memory trying to service too many requests.

This aspect of the issue has been tricky to reproduce consistently so if anyone has any information to prove/disprove that theory we'd love to hear it.

@AamenaSaiyed
Copy link

@robhogan
I need help for this cause I am facing issue when i upgrading my expo project from 45 to 47

Where I get stuck due to this released patch is not working for me.

Screenshot 2023-06-26 at 2 43 11 PM

@matheusnogs
Copy link

I am experiencing this same issue on 0.71.11.

Here are some info of my system. Let me know if you need more info:

expo-env-info 1.0.5 environment info:
System:
OS: macOS 12.5.1
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 18.12.1 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 9.5.1 - /usr/local/bin/npm
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
IDEs:
Android Studio: 2022.1 AI-221.6008.13.2211.9514443
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
npmPackages:
expo: ~47.0.12 => 47.0.13
react: 18.2.0 => 18.2.0
react-native: 0.71.11 => 0.71.11
npmGlobalPackages:
eas-cli: 3.13.3
expo-cli: 6.3.8
Expo Workflow: managed

@valevarela2612
Copy link

Same issue, con react natiive 0.65.3 (latest patch) how can we fix this? Is there going to be a patch? I can't upgrade all my app since I have to upgrade navigator too and it's going to resolve in unstable application, having same issues on 16 apps, rn 0.64, etc...

@robhogan
Copy link
Contributor

Same issue, con react natiive 0.65.3 (latest patch) how can we fix this? Is there going to be a patch? I can't upgrade all my app since I have to upgrade navigator too and it's going to resolve in unstable application, having same issues on 16 apps, rn 0.64, etc...

0.65 is outside the support window, I'm afraid we won't be backporting a fix that far. The server.rewriteRequestUrl workaround should work for you though, see #36794 (comment) for details and other workarounds.

@robhogan
Copy link
Contributor

@matheusnogs, @dennisdelima21pe - thanks for the reports, but it looks like you're both using Expo 47, with managed workflows. This has the native parts of React Native 0.70 "baked in" to Expo Go - updating react-native in your project dependencies doesn't change that, and this fix includes a native component.

You'll need to wait for an Expo release built with a fixed React Native version, or possibly move to a dev client workflow (I'm not an Expo expert and don't know whether updating RN native is supported that way).

@Spxc
Copy link

Spxc commented Jun 27, 2023

  • leak on node (I'm u

This seems to be a temporary workaround as you've written, and eventually Metro crashes due to a memory leak. Anyone know what's causing the leaks? Randomly started happening after XCode 14.3

This is a good question but I'm 90% certain there's no leak as such - rather a loop between Metro and client where the failure to symbolicate causes a reload, which then raises an error that fails to symbolicate, etc. In some circumstances that means Metro is dealing with multiple parallel bundling and symbolication requests and simply runs out of memory trying to service too many requests.

This aspect of the issue has been tricky to reproduce consistently so if anyone has any information to prove/disprove that theory we'd love to hear it.

Thank you for getting back to me!

Yeah very understandable. So after doing some testing, this issue is not present on devices/simulators running iOS 14 & 15. It instantly starts when running on iOS 16 device. (Running XCode 14.3)

Creating a iOS 15 or 14 simulator "fixes" the leaks, in such a way that we can develop without restarting Metro every 5 minutes :) So as you've stated, seems to be an issue with the symbolic with Metro

@Praveencena88
Copy link

Praveencena88 commented Jul 4, 2023

even after building the app in iOS 15, still the issue is occurring

robhogan added a commit that referenced this issue Jul 4, 2023
…7501)

Summary:
Pull Request resolved: #37501

This is the iOS side of the fix for #36794.

That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).

Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](react-native-community/discussions-and-proposals#646) to pass to the JS engine, even where the request URL isn't JSC-safe.

We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).

For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.

For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.

Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL

Reviewed By: huntie

Differential Revision: D45950661

fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
@mjmasn
Copy link
Contributor Author

mjmasn commented Jul 5, 2023

Closing this issue as it has been fixed and it looks like patch releases have been done for 0.69 and above. Would be grateful if someone could lock it as well as it's not exactly attracting useful replies at this point...

@mjmasn mjmasn closed this as completed Jul 5, 2023
@kelset
Copy link
Contributor

kelset commented Jul 5, 2023

actually there's one more 0.70 patch needed, I forgot to cherry-pick a commit 🤦‍♂️ it will be out soon, after that I'll post an update here and we can lock it 👍

kelset pushed a commit that referenced this issue Jul 5, 2023
…7501)

Summary:
Pull Request resolved: #37501

This is the iOS side of the fix for #36794.

That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).

Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](react-native-community/discussions-and-proposals#646) to pass to the JS engine, even where the request URL isn't JSC-safe.

We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).

For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.

For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.

Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL

Reviewed By: huntie

Differential Revision: D45950661

fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
@kelset
Copy link
Contributor

kelset commented Jul 5, 2023

👋 everyone!

As briefly mentioned by @mjmasn above, we have now released patches for all recent versions of React Native to address this problem: 72, 71, 70 and 69 latest patches all contain the fixes made by @robhogan (huge thanks to him for his work👏).

Please upgrade to those versions as soon as possible - and in particular please upgrade to a react native version that is part of the release support window policy; versions not in the window are not receiving any new patches.

For other issues please open new, dedicated issues and provide repros and information to help the maintainers understand your problem.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 5, 2023
@kelset kelset unpinned this issue Jul 5, 2023
@robhogan
Copy link
Contributor

robhogan commented Jul 5, 2023

Just a final note, this is now fixed in React Native in versions:

Users of older versions may try the workarounds and further details in this comment.

Expo users will need to wait until their version of Expo SDK picks up the native side of these fixes - please track expo/expo#22008.

If you're using a "fixed" version and still seeing this issue, please open a new issue with as much detail as you can. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs: Attention Issues where the author has responded to feedback. Platform: iOS iOS applications. Resolution: Fixed A PR that fixes this issue has been merged. Tech: Bundler 📦 This issue is related to the bundler (Metro, Haul, etc) used.
Projects
None yet
Development

No branches or pull requests