-
Notifications
You must be signed in to change notification settings - Fork 903
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
make React Native autolinkable #865
Comments
I prefer the auto linking, since the react native libraries change a lot lately! |
|
Yes, this has been long on my plate as well. This is a great feature and I think we should ship it with the I am going to write it down and see what's needed. |
This is already done on RN master. See: https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/template/ios/Podfile#L7 and facebook/react-native#28077 as a followup to make the name less confusing. No need to track it here, so closing. |
It's not and I actually question whether it's not going to cause even more issues. See https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L8, it assumes a path. Hidden hardcoded path & optional use of
|
Fortunately, it's not shipping yet so we got time to improve it -> facebook/react-native@a35efb9#diff-1c007079c085ea0a9262971dc43e6cea My suggestion: call Without this change, users will need to explicitly pass path to |
CC: @alloy let me know what you think - this will be a breaking change as it's a non-backwards-compatible addition (requires change to Podfile after you upgrade to a newer React Native). We got time to ship it as a part of 0.63. |
I actually would like to get rid of all the local path faffing. Users should retain control over what pieces of RN they actually need (i.e. it should be in their |
Forgot to include some details; I’m thinking of a CocoaPods plugin that is able to treat |
Sure, do you have any ETA or write-up on how you'd like to move on from this? This sounds interesting, but I am not familiar with how CocoaPods work and whether this would be easy to implement with our current behavior in mind. We probably don't want to introduce a lot of breaking changes and at the same time, realistically speaking, we haven't fully deprecated and removed legacy link code yet (a lot of work needed to do proper house keeping). Long story short, I'd like to help with this! As much as I like the aforementioned improvement, I would treat it as a parallel track. I was thinking to just move the Example (after line 34):
Otherwise, it's going to ship with 0.63 and degrade monorepo support that we're working to improve. |
Nothing yet. It’s probably a month or so out on my roadmap.
Ace, I’ll definitely loop you in closer to that time 👌
Sure, good call 👍
My concern still stands, though; moving the list of RN deps out of the user’s How would you solve that and does that solution outweigh leaving the noisy but explicit paths in the |
I see. In this case, it's probably worth revisiting - my understanding was that this has been already decided and agreed to be the best way to go forward.
TBH, I don't have anything against RN dependencies being explicitly declared in a Podfile. Depending on whether the aforementioned abstraction ends up being included in As far as the path itself, the |
I like that 👍 |
Describe the Feature
Right now we need to add a lot of pod specs to
link
react-nativecheck this https://github.com/facebook/react-native/blob/master/template/ios/Podfile#L42
This makes it hard to newcomers and also hard to support monorepo with yarn hoist, as we need to change from
../node_modules/react-native
to
../../../node_modules/react-native
Possible Implementations
getNodeModulesPath('react-native')
helper function for cocoapodsor
react-native
- have a react-native.config.js that tells how to properly link react-native itselfThe text was updated successfully, but these errors were encountered: