Open letter - Road to 7.0.0 about react-native-fbsdk-next

[mikehardy]

rn-firebase maintainer here 👋 😅 - yes lerna has been a good experience

you will definitely want a core / central / always-installed package to share some infrastructure and versioning etc

a monorepo is the only way I know of to handle underlying library splits well so it does seem like a good fit

[thebergamo]

It's automated by github actions.
That's fine if you broke it we can fix it later on :)

[mikehardy]

Typescript is out as @beta tag on npmjs.com

formal version is v7.0.0-beta.1 on npmjs.com and on the beta branch, got it all working.

Now it can incubate - and this is a call for testers, any interested parties should test this in their projects and report problems before end of first week of January!

@rnike --> 🏆 !

[iduuck]

For point "Split the repository in a monorepo (using lerna (?))" I would say, it would make sense to have something like the core (see rn-firebase), and then multiple things on top, in my eyes, lerna makes completely sense.

[kmsbernard]

Although it is not directly related with the functionality, detailed & user-friendly documentation will be big help.

[mikehardy]

Typescript has a PR in progress but looks like the PR needs someone to pick it up and give it some polish so it is merge-able
SDKs are current now!
Updated description above

[thebergamo]

Amazing! First week of January I've to implement a new feature in my app related to Facebook and will be able to test the beta on iOS will put my feedback here :)

Next step would be start splitting into modules.

Any guidance to have something similar to rn-firebase is very welcomed @mikehardy

[thebergamo]

I agree! Need to take a deeper look into rn-firebase:)

[g-dimitry]

About the migration to TS. I could start now but i guess this will break the deployment process (is it a script or is it manual ?)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rnike]

TypeScript migration #155

[mikehardy]

@rnike you win all my internet points for the day for doing that PR, thank you 🏆

[rnike]

Thank you @mikehardy for all the help, finally we can install beta from npm, the AEM logger(#165) is still in need for us to actually test it on the production app, not meant to be in hurry but reviews are welcome

[mikehardy]

Okay, I will prioritize that one. Can merge it into beta branch easy I think

[mikehardy]

My best guidance is don't, unless you really really need to. Multimodule monorepos are kind of a pain in the butt haha. When you can't avoid them, then sure, but if there is not a clear reason I wouldn't...

[rnike]

Checked the typescript checkbox, it's done in #155

[gvillenave]

+1 for splitting into multiple packages and separate Core/Login/Share, one issue with iOS App Store submission for example is that even if you only use FBSDKLoginKit the app still is considered using Photo Library and Microphone access (for which you have to provide justifications for), because the APIs are referenced by FBSDKShareKit. So it would be definitely nice to be able to only consume the packages you need :)

[mikehardy]

Permission splitting for app store approval is one of the valid reasons to have multiple packages @gvillenave, so that's a good point. There are still other ways to do it perhaps than a mono-repo, something worth mentioning - for instance on the iOS side react-native-permissions has you include more targetted podspec files https://github.com/zoontek/react-native-permissions - however that puts a requirement on the user to include what they want at the native level (in podspec) vs allowing auto-linking to "just handle it". So there are still non-monorepo ways to do it but they involve tradeoffs between native vs javascript implying different choices about who should do the work (monorepo -> maintainers do the work, auto-linking handles it for devs, podspec -> integrating users do the work, cocoapods handles it)

I'd go for monorepo in that case even though it's a maintainer pain. In the long run the integration effort results in extra issues from confused users that adds up over time and is synchronous (more irritating, for maintainers) vs async maintainer work

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.