Migration path from current DefinitelyTyped RN typings

[alloy]

This ticket describes the differences with the existing manually maintained DT typings and the migration path to these converted ones.

• TypeScript does not have a build in way to deal with different files for different platforms. Proposal: Allow typescript to type check modules using react-native's module resolution TypeScript#21926

  • How can we offer distinctive sets of typings for iOS and Android (eg @types/react-native-ios, @types/react-native-android) and let the user configure them for their project?
  • Can DT handle this?
  • And can other DT packages that depend on RN use this too?

• Many (all?) components are no longer class based, but rather function or even ‘abstract’ based. Because classes can be used as types in TS, there may be user code that refers to it that way but now needs to change to typeof View. This does not seem like an issue we need to resolve, as it’s simply not in line with reality. TS2749

• Component props interfaces are exported, whereas upstream Flow code requires the user to do React.ElementProps<typeof View>. We currently export these separate props types as a migration convenience, but they are annotated as being deprecated.

  • There are many more component props interfaces still missing.
  • Should we add ElementProps to the React DT typings and is it correct that ElementProps does not include ref (as we use ComponentPropsWithoutRef of the React DT typings)?

• Allow interface merging of RN NativeModules. These contain the user's own and 3rd party native modules and so should allow for the user to provide typings. f41628c

• Style type param passed to StyleSheet.create<T>(…) needs to by a type alias, not an interface; because Index signature is missing in type (only on interfaces, not on type alias) TypeScript#15300 (comment). But also there's no longer a need to define the type upfront anymore (which perhaps was already no longer needed).

[alloy]

We should consider providing a codemod that users can apply to their codebase to upgrade some/all of these.

[alloy]

• TypeScript does not have a build in way to deal with different files for different platforms.

  • How can we offer distinctive sets of typings for iOS and Android (eg @types/react-native-ios, @types/react-native-android) and let the user configure them for their project?

Perhaps we can find a way to alias @types/react-native-ios to @types/react-native in tsconfig.json, that way people can have different configs per platform and importing from the react-native namespace should still work.

TS doesn't need to resolve specific extensions, as currently we’re generating distinctive sets per platform and dropping the platform file extension.

• And can other DT packages that depend on RN use this too?

Additionally we could update the actual @types/react-native package to import and re-export the top-level exports of both @types/react-native-ios and @types/react-native-android so they can possibly depend on them in a platform independent manner? Unsure how feasible this is.

[alloy]

Could it help if we were able to release DT packages with version suffix? E.g. 0.64.0-ios and 0.64.0-android.

[alloy]

Also need to decide what to do with fallout in all DT packages that depend on the RN typings, assuming there will be.

[alloy]

One solution to providing the packages using alternate names would be to use declare module "react-native/..." {} for each module, e.g. see https://github.com/DefinitelyTyped/DefinitelyTyped/pull/49914/files#diff-8b9d499e69407ece17612b602d5355d8a1c8b2e5fdb6628e288638aab682ef29R7

[ZihanChen-MSFT]

Looks like TypeScript people are working on supporting this scenario