Use align-deps to help migrate apps to the New Architecture

[motiz88]

For app maintainers to migrate to the New Architecture, all of their native dependencies must support the New Architecture as well. This isn't the same as being merely compatible with some React Native version 0.x, since (for the time being) the New Architecture is opt-in.

A problem that has come up is that it's not easy to know ahead of time, as an app maintainer, whether all of your dependencies have new versions available that are compatible with the New Architecture. In the worst case, you might sink time and effort into beginning an upgrade, only to get blocked halfway by some third-party library and have to abandon the effort for an unknown length of time.

The idea here would be to add information to align-deps's database about various common libraries' New Architecture readiness, such that (ideally) we can recommend align-deps as part of the official New Architecture migration guide for app maintainers. In doing this, we want to (1) increase the likelihood of apps migrating successfully on the first try, (2) create visibility in the ecosystem (and thus momentum and excitement) around popular libraries migrating to the New Architecture.

There are some questions around how we source this information reliably at scale (e.g. combine efforts with https://reactnative.directory/ ?), but in the short term leveraging align-deps's standalone database of packages seems like a good way to jumpstart this capability for relatively low effort.

NOTE: I'm only lightly familiar with align-deps and the New Architecture, so I've kept this super high-level and am not opinionated on the details.

cc @cortinico @tido64 @afoxman @huntie @cipolleschi

---

update by @kelset: changed dep-check to align-deps ;)

[tido64]

We can probably use the list in reactwg/react-native-new-architecture#6 as a starting point.

[tido64]

We can probably use the list in reactwg/react-native-new-architecture#6 as a starting point.

I have a draft PR with only these packages. The rest are null-ed out.

[cortinico]

I think this would be an amazing addition to the New Architecture migration story.
It has been asked previously by the community (see facebook/react-native-website#3275).

As for the technical side: we don't have a simple way to know if a library is New Architecture compatible. In general, relying on codegenConfig inside package.json is a good indicator. However there might be other libraries which are New Architecture compatible and not using the Codegen. We should think about an indicator that allows us to easily understand this (like another field in the package.json or so).

[tido64]

Is codegenConfig always present in a fully migrated package? I extended the script we use to check for updated packages to include it:

Capability	Name	Version	Latest	New Arch	Homepage
animation	react-native-reanimated	^2.10.0	=		https://github.com/software-mansion/react-native-reanimated#readme
base64	react-native-base64	^0.2.1	=		https://github.com/eranbo/react-native-base64#readme
checkbox	@react-native-community/checkbox	^0.5.8	0.5.12		https://github.com/react-native-community/react-native-checkbox#readme
clipboard	@react-native-clipboard/clipboard	^1.10.0	1.11.0		https://github.com/react-native-clipboard/clipboard#readme
datetime-picker	@react-native-community/datetimepicker	^6.0.2	6.3.2		https://github.com/react-native-community/datetimepicker#readme
filesystem	react-native-fs	^2.18.0	2.20.0		https://github.com/itinance/react-native-fs#readme
floating-action	react-native-floating-action	^1.22.0	=		https://github.com/santomegonzalo/react-native-floating-action#readme
gestures	react-native-gesture-handler	^2.6.0	=	Yes	https://github.com/software-mansion/react-native-gesture-handler#readme
hooks	@react-native-community/hooks	^2.8.0	2.8.1		https://github.com/react-native-community/hooks#readme
html	react-native-render-html	^6.1.0	6.3.4		https://meliorence.github.io/react-native-render-html/
jest	jest	^26.6.3	29.0.2		https://jestjs.io/
lazy-index	@rnx-kit/react-native-lazy-index	^2.1.7	=		https://github.com/microsoft/rnx-kit/tree/main/packages/react-native-lazy-index#readme
masked-view	@react-native-masked-view/masked-view	^0.2.7	=		https://github.com/react-native-masked-view/masked-view#readme
modal	react-native-modal	^13.0.0	13.0.1		https://github.com/react-native-community/react-native-modal
navigation/native	@react-navigation/native	^6.0.8	6.0.12		https://reactnavigation.org
navigation/stack	@react-navigation/stack	^6.2.0	6.2.3		https://reactnavigation.org/docs/stack-navigator/
netinfo	@react-native-community/netinfo	^9.0.0	9.3.0		https://github.com/react-native-netinfo/react-native-netinfo#readme
popover	react-native-popover-view	^5.0.0	5.1.2		https://github.com/steffeydev/react-native-popover-view#readme
safe-area	react-native-safe-area-context	^4.3.1	4.3.3	Yes	https://github.com/th3rdwave/react-native-safe-area-context#readme
screens	react-native-screens	^3.14.1	3.17.0	Yes	https://github.com/software-mansion/react-native-screens#readme
shimmer	react-native-shimmer	^0.5.0	0.6.0		https://github.com/oblador/react-native-shimmer
sqlite	react-native-sqlite-storage	^6.0.1	=		https://github.com/andpor/react-native-sqlite-storage
storage	@react-native-async-storage/async-storage	^1.17.10	=		https://github.com/react-native-async-storage/async-storage#readme
svg	react-native-svg	^12.3.0	13.1.0	Yes	https://github.com/react-native-community/react-native-svg
test-app	react-native-test-app	^1.6.9	1.6.13		https://github.com/microsoft/react-native-test-app
webview	react-native-webview	^11.23.0	11.23.1		https://github.com/react-native-webview/react-native-webview#readme

Reanimated isn't listed here because New Arch support is still in RC.

[cortinico]

Is codegenConfig always present in a fully migrated package? I extended the script we use to check for updated packages to include it:

As mentioned above, not always. There might be packages without codegenConfig which support the New Architecture. That being said, I think it's anyway a good indicator.

[kelset]

This conversation I think is very close to what the RNDirectory is trying to achieve through this: react-native-community/directory#870

cc @Simek

It'd be great to decide a standard way to communicate new arch support, and then "enforce it" by having both dep-check and directory leverage it as the official way. At that point we can communicate in all the 3 places (dep-check, RN docs website, RNDirectory) that doing "XXX" is the one way.

[tido64]

I've been wondering if it makes more sense for each package to add a field that signals their new-arch readiness. It would allow cli to warn when autolinking, dep-check/directory to generate the compat table, and docs to be automatically updated.

Edit: The field does not need to be binary, it could signal compatibility, e.g. "ready" -> works fine as-is, "full" -> codegen and extra steps to ensure better experience.