refactor!: library source folder, types and methods

[jeremybarbet]

Update:

I would appreciate a good review on that!

Summary of changes:

• Remove default export import RNIap from 'react-native-iap'. You now import by name directly e.g. import { requestPurchase } from 'react-native-iap'

• Restructure files:

  • context: contains the react context for hooks usage
  • hooks: contains the hook to work along with the context
  • internal: contains some utils used between files
  • modules: contains a file for each platform (ios/android/amazon), which their specific methods exposed (e.g. android — flushFailedPurchasesCachedAsPending, ios — presentCodeRedemptionSheetIOS). All the typescript interfaces are also defined per platform in there. Contains as well a common.ts that shares functions that are called by the 3 platforms (e.g. requestPurchase)
  • types: Typescript types. Most of the types are defined in common.d.ts because shared between all the modules
  • eventEmitter: React event listener to subscribe to.
  • purchaseError: Class for the Purchase error

Everything is exported at the root (apart from the internal folder)

---

So this PR splits:

• each modules in their own file with native typings directly
• remove some types non used and imported from external library
• get ride of all the jsdoc parameters to use directly in the javascript parameters to avoid naming the params twice each time
• get ride of the return types, it's coming from each modules directly

@andresesfm @hyochan

• Do you have any objection on using external libraries for typings? I published theses two for apple/google types related to IAP @jeremybarbet/apple-api-types, @jeremybarbet/google-api-types. That's making some clean up in the types we were having.

• I would like to drop support for default export aka RNIap.finishTransaction, RNIap.requestSubscription and exports all theses methods through the destructured import import { finishTransaction, requestSubscription } from 'react-native-iap'. We don't really have a good process on how to handle breaking change at the moment, that can be done in another PR, just opening the conversation.

(@hyochan: is it fine I'm tagging you in here on kinda everything 😅? I don't want to spam you if you don't have time for it. Since I'm breaking/changing a lot of stuff, you might have opinion on it)

[andresesfm]

@jeremybarbet I was thinking about this exact problem as I'm adding some other properties that are exclusive to Android. What would you think about typing objects like this:

type RequestPurchase{
commonProperty: type
android: {
   androidProp: type
}
ios: {
 otherProp: type
}
}

It would clean up a lot of our property names and maybe be less confusing that having them with the never type. Very curious about your thoughts on this one

[jeremybarbet]

Yep, I like that, I think it would be an easy and clean way to treat platform-specific arguments.

never is really good when you CAN'T define two arguments at the same time, so if we need it somewhere I would still recommend using it. (cf: https://github.com/dooboolab/react-native-iap/pull/1802 we can use both android/ios arguments simultaneously so it didn't make sense to use never in there)

[andresesfm]

@jeremybarbet Thank you for such a fantastic job. I added a few questions.

I also wanted to discuss the plan of integrating this on main. Should we merge it on next once 19.0.0 lands? what are your thougs?

[jeremybarbet]

Theses changes are definitely breaking. The best move would be to merge and tag this in 9.x within the next branch.

[andresesfm]

Partially integrated into 10.1.0