-
Notifications
You must be signed in to change notification settings - Fork 4.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
expo-camera peer dependency conflict with npm 7+ due to @koale/useworker #17846
Comments
you can work around this by using the |
Thank you @brentvatne I haven't been having problems building since I'm using yarn. However, I am concerned about the underlying problem rather than the symptom. What would be involved in fixing the underlying problem (i.e. updating the react dependency for @koale/useworker)? |
correct - updating the react dependency for |
Thanks, @brentvatne |
This issue is stale because it has been open for 60 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. |
ran to this error and fixed it after running the command npx expo install expo-updates |
Thank you for filing this issue! |
Wait what? You aren't putting priority on an issue where those that use expos latest SDK can ask users for permissions to use the camera? Don't you find that a pretty central functionality that we as developers should be able to use with your software? |
any luck with this? |
i'm still having this issue |
The "Basic Camera usage" example from expo-camera usage doc works in Expo Snack web view, see example: I have attached zip of project export from Expo Snack: basic-camera-usage.zip Extracting the {
"main": "node_modules/expo/AppEntry.js",
"scripts": {
"start": "expo start",
"android": "expo start --android",
"ios": "expo start --ios",
"web": "expo start --web"
},
"dependencies": {
"expo": "~48.0.18",
"expo-status-bar": "~1.4.4",
"react": "18.2.0",
"react-native": "0.71.8",
"expo-camera": "~13.2.1"
},
"devDependencies": {
"@babel/core": "^7.20.0"
},
"private": true
} The ...
"node_modules/expo-camera/node_modules/@koale/useworker": {
"version": "4.0.2",
"resolved": "https://registry.npmjs.org/@koale/useworker/-/useworker-4.0.2.tgz",
"integrity": "sha512-xPIPADtom8/3/4FLNj7MvNcBM/Z2FleH85Fdx2O869eoKW8+PoEgtSVvoxWjCWMA46Sm9A5/R1TyzNGc+yM0wg==",
"dependencies": {
"dequal": "^1.0.0"
},
"peerDependencies": {
"react": "^16.8.0"
}
},
... |
Any updates? My application uses camera and it is no longer possible to generate builds for the play store using expo , because of this problem, as I did not find a solution I am having to abandon expo |
# Why `@koale/useworker` is only used for Web QR code scanning and has been causing some issues due to lack of maintenance. Fixes: #17846 Related: #23296, and the PR to revert its 'fix' expo/expo-cli#4746 # How Refactors the existing code to use vanilla JS 1. We create a inline webworker by creating an inline blob with `qrWorkerMethod.toString()` (code adapted from `@koale/useworker`) 2. Create a smaller wrapper that tracks messages being sent to the worker via a queue of promises As the worker is synchronous and will receive messages in order a simple First In First Out queue should suffice. This does _slightly_ change the functionality of the existing code. 1. Previously we created a new Worker for every instance of `<Camera />`. Now a single worker is shared across all instances. 1. As the worker is declared in the global scope, it is created regardless if QR code scanning is enabled. We could lazy initialise it, but because its extremely small and inline (no network requests) I don't see this being an issue. I also removed an extra `useEffect` hook by moving its logic into the cleanup step of the enabling hook.
# Why `@koale/useworker` is only used for Web QR code scanning and has been causing some issues due to lack of maintenance. Fixes: #17846 Related: #23296, and the PR to revert its 'fix' expo/expo-cli#4746 # How Refactors the existing code to use vanilla JS 1. We create a inline webworker by creating an inline blob with `qrWorkerMethod.toString()` (code adapted from `@koale/useworker`) 2. Create a smaller wrapper that tracks messages being sent to the worker via a queue of promises As the worker is synchronous and will receive messages in order a simple First In First Out queue should suffice. This does _slightly_ change the functionality of the existing code. 1. Previously we created a new Worker for every instance of `<Camera />`. Now a single worker is shared across all instances. 1. As the worker is declared in the global scope, it is created regardless if QR code scanning is enabled. We could lazy initialise it, but because its extremely small and inline (no network requests) I don't see this being an issue. I also removed an extra `useEffect` hook by moving its logic into the cleanup step of the enabling hook.
`@koale/useworker` is only used for Web QR code scanning and has been causing some issues due to lack of maintenance. Fixes: #17846 Related: #23296, and the PR to revert its 'fix' expo/expo-cli#4746 Refactors the existing code to use vanilla JS 1. We create a inline webworker by creating an inline blob with `qrWorkerMethod.toString()` (code adapted from `@koale/useworker`) 2. Create a smaller wrapper that tracks messages being sent to the worker via a queue of promises As the worker is synchronous and will receive messages in order a simple First In First Out queue should suffice. This does _slightly_ change the functionality of the existing code. 1. Previously we created a new Worker for every instance of `<Camera />`. Now a single worker is shared across all instances. 1. As the worker is declared in the global scope, it is created regardless if QR code scanning is enabled. We could lazy initialise it, but because its extremely small and inline (no network requests) I don't see this being an issue. I also removed an extra `useEffect` hook by moving its logic into the cleanup step of the enabling hook.
Summary
The expected behavior is that when I install expo-camera in a React Native app created by running
npx react-native init
, which uses react 17.0.2, there will be a version of react that satisfies all peerDependencies.However, I get this error:
Unable to find a version of react that satisfies the following peerDependencies: 17.0.2 and ^16.0.0 || ^17.0.0 || ^18.0.0 and ^16.8.0 and ^16.0.0 || ^17.0.0 and ^16.8.0 || ^17.0.0
.Managed or bare workflow? If you have
ios/
orandroid/
directories in your project, the answer is bare!bare
What platform(s) does this occur on?
iOS
SDK Version (managed workflow only)
No response
Environment
expo-env-info 1.0.3 environment info:
System:
OS: macOS 12.1
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.11.1 - ~/.nvm/versions/node/v16.11.1/bin/node
Yarn: 1.22.18 - ~/.nvm/versions/node/v16.11.1/bin/yarn
npm: 8.0.0 - ~/.nvm/versions/node/v16.11.1/bin/npm
Watchman: 2022.05.23.00 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.2, iOS 15.2, macOS 12.1, tvOS 15.2, watchOS 8.3
Android SDK:
API Levels: 25, 27, 29, 30, 31
Build Tools: 27.0.3, 29.0.2, 30.0.1, 30.0.2, 31.0.0
System Images: android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom
IDEs:
Android Studio: 2021.1 AI-211.7628.21.2111.8309675
Xcode: 13.2.1/13C100 - /usr/bin/xcodebuild
npmPackages:
expo: ^45.0.0 => 45.0.5
react: 17.0.2 => 17.0.2
react-native: 0.68.2 => 0.68.2
npmGlobalPackages:
expo-cli: 5.0.3
Expo Workflow: bare
Reproducible demo
Run the following commands:
npx react-native init expovideo
cd expovideo
npx install-expo-modules@latest
expo install expo-camera
Then run
npx check-peer-dependencies --findSolutions
. The output includes this:❌ Unable to find a version of react that satisfies the following peerDependencies: 17.0.2 and ^16.0.0 || ^17.0.0 || ^18.0.0 and ^16.8.0 and ^16.0.0 || ^17.0.0 and ^16.8.0 || ^17.0.0
The error is due to the package @koale/useworker:
❌ react ^16.8.0 is required by @koale/useworker@4.0.2) (17.0.2 is installed)
The text was updated successfully, but these errors were encountered: