Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

EvanBacon
Copy link
Contributor

@EvanBacon EvanBacon commented May 26, 2021

Why

Note I've updated the package to support Expo SDK 46 and React Native 69. This no longer requires react-native-webrtc to depend on @expo/config-plugins directly. Users can continue to use the out-of-tree plugin while we wait for this PR to be merged.

With Expo SDK 41 we've rolled out an interface called config plugins which lets users add native modules that aren't in the Expo Go app to their native cloud builds and locally when prebuilding.

This is a highly requested package so I've created the plugin personally.

How

  • Added a app.plugin.js as the main entry point to the plugin. Plugins must run in at node LTS environments (currently that means 14 and greater).

Test Plan

  • Run npm pack in the package
  • Install the package in a managed Expo project yarn add react-native-webrtc@../react-native-webrtc/react-native-webrtc-1.89.1.tgz
  • Then add react-native-webrtc to the plugins array and build the native app locally with expo prebuild and yarn ios, yarn android. We plan to further automate these steps with expo install and expo run commands.
  • App built correctly without any errors.
    • Running expo config --type introspect showed all of the desired config changes in AndroidManifest, Info.plist, and entitlements files.

Modified some values and in the config plugin and updated with expo prebuild and yarn ios, yarn android.

@saghul
Copy link
Member

saghul commented Jul 6, 2021

Looking good! I’m on leave ATM but will review this once I’m back!

@EvanBacon
Copy link
Contributor Author

EvanBacon commented Jul 13, 2021

People can use this out-of-tree solution in the meantime @config-plugins/react-native-webrtc. It's not versioned with the code so YMMV over time, but for now it works great! We also have one for callkeep.

Copy link
Member

@saghul saghul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, I finally managed to give this a try. I left a single comment, but after giving this a try I'm honestly not very inclined to merge it.

After this change, we have a whopping 2800 packages as dependencies 😱 (check with `npm ls | wc -l) vs the 12 the project has today.

Now, I do want to facilitate the lives of those using Expo, and AFAIS they just need to use the package you created (https://github.com/Expo/config-plugins/tree/master/packages/react-native-webrtc) right? What problems do you foresee with that approach? The manifest items the package takes care of have not changed in years, so I'm not concerned about hypothetical incompatibilities.

Thoughts?

@EvanBacon
Copy link
Contributor Author

@saghul the dependency you're concerned about has many dependencies in common with a standard React Native project so it's just accessing the code that's already in the node modules folder.

We can stick with the @config-plugins/react-native-webrtc package for a while, but it would be good to have it versioned somehow, and we should also land the markdown changes so users have clear documentation on how to get things working.

Further, I've noticed that the config plugin doesn't fully work with package due to a couple of issues. The main one being that Bitcode is not available on iOS, causing the binary to not be fully compilable in Release mode:

❌  ld: '/Users/expo/Library/Developer/Xcode/DerivedData/CustomGo-ghgjpyndamtfsoeycnvxcexmmzsi/Build/Intermediates.noindex/ArchiveIntermediates/CustomGo/BuildProductsPath/Release-iphoneos/XCFrameworkIntermediates/WebRTC/WebRTC.framework/WebRTC' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. file '/Users/expo/Library/Developer/Xcode/DerivedData/CustomGo-ghgjpyndamtfsoeycnvxcexmmzsi/Build/Intermediates.noindex/ArchiveIntermediates/CustomGo/BuildProductsPath/Release-iphoneos/XCFrameworkIntermediates/WebRTC/WebRTC.framework/WebRTC' for architecture arm64

I guess running this script fixes that, but we've spec'd config plugins to avoid running fetch requests. Generally all of the native code is shipped in the node module. I'd love to get this fixed, so let me know if you have any ideas for when this should run.

Another issue is that this module often causes the yarn.lock/Podfile.lock to get corrupted, requiring the lock files to be nuked.

@saghul
Copy link
Member

saghul commented Aug 10, 2021

@saghul the dependency you're concerned about has many dependencies in common with a standard React Native project so it's just accessing the code that's already in the node modules folder.

Good point, I'll check it out again.

The main one being that Bitcode is not available on iOS, causing the binary to not be fully compilable in Release mode:

Does Expo default to using bitcode? Why? It's not mandatory and the advantages are not a clean cut IMHO (Jitsi Meet is built with bitcode, but have no other choice because we have an Apple Watch target). The WebRTC framework with bitcode is ~1GB uncompressed...

I guess running this script fixes that, but we've spec'd config plugins to avoid running fetch requests. Generally all of the native code is shipped in the node module. I'd love to get this fixed, so let me know if you have any ideas for when this should run.

As I mentioned, the framework is just huge, I don't see a way around it TBH. Well yes, defaulting to no bitcode :-)

Another issue is that this module often causes the yarn.lock/Podfile.lock to get corrupted, requiring the lock files to be nuked.

I have never run into this myself, can you show an example? Podfile thrashing is usually due to a mismatched CocoaPods version. Can't speak about yarn since I don't use it.

@jesse-savary
Copy link

@saghul is there any way that the bitcode could be shipped as a separate NPM package? If it's not possible to ship an optional/addon package perhaps a react-native-webrtc-heavy could be created as an alternative, similar to what `react-native-v8 does: https://github.com/Kudo/react-native-v8/#v8-variants

- Expo SDK 46 versions the `@expo/config-plugins` package in a user's project meaning this package no longer needs to depend on `@expo/config-plugins`.
- Update to meet the latest requirements.
- Use latest designations for installation guide.
@8BallBomBom

This comment was marked as outdated.

@stale stale bot added the wontfix There are no plans to work on this label Oct 17, 2022
@stale stale bot closed this Oct 24, 2022
@8BallBomBom
Copy link
Member

Needs updating to reflect the bitcode removal but maybe include in the next stable update?

@saghul
Copy link
Member

saghul commented Oct 24, 2022

maybe include in the next stable update?

👍 I won't have time to work on this though.

@8BallBomBom
Copy link
Member

Never really used Expo but i can definitely test the pr and ensure things are up to scratch for inclusion 👍🏻

@8BallBomBom 8BallBomBom added enhancement Enhancement of an existing feature and removed wontfix There are no plans to work on this labels Mar 21, 2023
@8BallBomBom
Copy link
Member

8BallBomBom commented Mar 21, 2023

Will need any up to date changes bringing in from here.


Will be looking to include an updated version of this with the New Arch update.
Then finally bring this to a close.

@8BallBomBom 8BallBomBom reopened this Mar 21, 2023
@stale stale bot added the wontfix There are no plans to work on this label May 26, 2023
@8BallBomBom 8BallBomBom removed the wontfix There are no plans to work on this label May 26, 2023
@react-native-webrtc react-native-webrtc deleted a comment from stale bot Jul 20, 2023
@react-native-webrtc react-native-webrtc deleted a comment from stale bot Jul 20, 2023
@8BallBomBom 8BallBomBom added waiting-response Waiting for a response from the contributor or reviewer documentation Improvements or additions to documentation needs-testing Testing is required and removed waiting-response Waiting for a response from the contributor or reviewer labels Jul 20, 2023
@8BallBomBom 8BallBomBom added the confirmed The issue has been confirmed label Sep 19, 2023
@8BallBomBom 8BallBomBom marked this pull request as draft February 6, 2025 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed The issue has been confirmed documentation Improvements or additions to documentation enhancement Enhancement of an existing feature needs-testing Testing is required
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants