Ability to skip autolinking for dependency for specific ios target

Describe the Feature

We use the same codebase for different apps in appstore, so we have different targets in pod file. For some of the apps we need to remove specific dependencies (for instance, we can’t use firebase admob library in target that is aiming for kids due to appstore policy).

Currently in react-native.config.js I can disable autolinking only for specific platfrom, but it would be good to be able to skip dependency for specific pod targets as well

Possible Implementations

I can imagine that it could be a specific property in react-native.config.jsin dependency configuration where I can putt targets that should be excluded from autolinking

module.exports = {
  assets: ['res/fonts'],
  dependencies: {
    'react-native-code-push': {
      platforms: {
        ios: {
          excludeFor: ['Target1'],
        },
        android: null,
        web: null,
      }
    }
  }
}

I think in ../node_modules/@react-native-community/cli-platform-ios/native_modules it could be possible to get this property for dependency and skip installation if current target is listed

[Charlie-Hua]

I ended up patching native_modules.rb to take packages_to_skip in use_native_modules!, so I can do this in my Podfile:

abstract_target 'Main' do
  # common dependencies, around 20
  use_native_modules!(packages_to_skip: ['RNFBAdMob'])

  target "InAppAddAllowed" do
    pod 'RNFBAdMob', :path => '../node_modules/@react-native-firebase/admob'
  end

  target "AppWithoutAdd" do
  end
end

here is the content of my patches/@react-native-community+cli-platform-ios+4.13.0.patch file

diff --git a/node_modules/@react-native-community/cli-platform-ios/native_modules.rb b/node_modules/@react-native-community/cli-platform-ios/native_modules.rb
index 2254158..397ca0a 100644
--- a/node_modules/@react-native-community/cli-platform-ios/native_modules.rb
+++ b/node_modules/@react-native-community/cli-platform-ios/native_modules.rb
@@ -12,7 +12,7 @@
 require 'pathname'
 require 'cocoapods'
 
-def use_native_modules!(config = nil)
+def use_native_modules!(config = nil, packages_to_skip: [])
   if (config.is_a? String)
     Pod::UI.warn("Passing custom root to use_native_modules! is deprecated.",
       [
@@ -44,6 +44,10 @@ def use_native_modules!(config = nil)
 
   packages.each do |package_name, package|
     next unless package_config = package["platforms"]["ios"]
+    if skipped_pod = packages_to_skip.find { |pod_name| package["platforms"]["ios"]["podspecPath"].include? "#{pod_name}.podspec" }
+      Pod::UI.notice "Skipping pod: #{skipped_pod}"
+      next
+    end
 
     podspec_path = package_config["podspecPath"]
 

[alloy]

In my opinion, which is very strong when it comes to options/configuration 😅, auto-linking should be as simple as it can be without the need for configuration. Any further customisation should be done entirely through normal CocoaPods [or Gradle] means.

The reason I feel this way is that I think it ends up hurting the user if we try to abstract away things that are already well covered by the amount of docs/issues/stackoverflow/blogs that exist for the underlying tool–in this case CocoaPods. Instead we would have to write and maintain new rn-cli specific documentation, meaning maintainers need to do more work and end-users have less chance of finding the right solution; which is a lose-lose situation.

In short, I think auto-linking should:

1. not ever try include dependencies on platforms the pod doesn’t support (added in https://github.com/react-native-community/cli/pull/1126)
2. auto-linking should skip pods that were already explicitly activated by the user prior to invoking auto-linking, thus allowing the user to provide custom configuration for that pod (already works this way)
3. auto-linking can be invoked from within specific targets, thus not affecting other targets (should already work this way)

Thus, I don’t think we should add this feature, furthermore I believe we should remove the ability to exclude pods for specific platforms. It would also be good to outline the above design in the auto-linking doc.