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

expo-camera peer dependency conflict with npm 7+ due to @koale/useworker #17846

Closed
stevehs17 opened this issue Jun 14, 2022 · 13 comments · Fixed by #23967
Closed

expo-camera peer dependency conflict with npm 7+ due to @koale/useworker #17846

stevehs17 opened this issue Jun 14, 2022 · 13 comments · Fixed by #23967
Assignees

Comments

@stevehs17
Copy link

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/ or android/ 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)

@stevehs17 stevehs17 added the needs validation Issue needs to be validated label Jun 14, 2022
@brentvatne
Copy link
Member

brentvatne commented Jun 14, 2022

alewin/useWorker#123

you can work around this by using the --legacy-peer-deps flag with npm install

@brentvatne brentvatne added Platform: web Using Expo in the browser Camera and removed needs validation Issue needs to be validated labels Jun 14, 2022
@stevehs17
Copy link
Author

stevehs17 commented Jun 23, 2022

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)?

@brentvatne
Copy link
Member

correct - updating the react dependency for @koale/useworker is one solution. another is to move off of that dependency in expo-camera

@brentvatne brentvatne changed the title expo-camera and React Native have a dependency conflict. expo-camera peer dependency conflict with npm 7+ due to @koale/useworker Jun 25, 2022
@stevehs17
Copy link
Author

Thanks, @brentvatne

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Sep 23, 2022
@github-actions
Copy link
Contributor

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.

@Buddimal-Liyanapathirana

ran to this error and fixed it after running the command npx expo install expo-updates

@expo-bot
Copy link
Collaborator

expo-bot commented Feb 4, 2023

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

@brentvatne brentvatne removed the stale label Feb 4, 2023
@minifisk
Copy link

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?

@freewill777
Copy link

any luck with this?

@freewill777
Copy link

i'm still having this issue

@sunnyrod
Copy link

sunnyrod commented Jul 29, 2023

The "Basic Camera usage" example from expo-camera usage doc works in Expo Snack web view, see example:
https://snack.expo.dev/@sunnyr/basic-camera-usage

I have attached zip of project export from Expo Snack: basic-camera-usage.zip

Extracting the package.json reveals that the example also uses react@18. What is Expo Snack doing differently that allows it to use expo-camera@13.2.1 which has dependency on @koale/useworker@4.0.2?

{
  "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 package-lock.json shows that @koale/useworker@4.0.2 has a peerDependency on react@16:

...
    "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"
      }
    },
...

@abramfh
Copy link

abramfh commented Aug 10, 2023

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

EvanBacon pushed a commit that referenced this issue Aug 16, 2023
# 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.
EvanBacon pushed a commit that referenced this issue Aug 23, 2023
# 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.
brentvatne pushed a commit that referenced this issue Sep 7, 2023
`@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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants