[EXPERIMENT] Migrate to Expo 52 with CNG and React Native 0.77 [NOMERGE]

[cardoso]

This goal of this PR is to figure out the best migration path. It's not currently meant to be merged. Many of the deleted files and commented out lines are in the process of being migrated.

Experiment findings (WIP)

These changes may be pursued separately in order to facilitate this migration with minimal disruption:

• Improve module resolution and require cycles by enforcing type-only imports:
  • Task: Update TypeScript to 5.7 and enable verbatim module syntax.
  • Effort: Mostly automated, no behavioral changes.
• Improve typings of api calls and state management logic
  • Task: Enable "noImplicitAny", remove usages of explicit any, convert remaining js files to ts, replace //@ts-ignore with //@ts-expect-error [description].
  • Effort: Mostly tooling-assisted, no behavioral changes.
• Reduce usage of legacy react-native dependencies
  • Task: Use alternatives to 'react-native-math-view' and others.
  • Effort: Manual, may cause behavioral changes

Automated code migration

For migration of patterns used in hundreds of files, ast-grep is a great tool.

Some examples used used in this PR:

Missing displayName in memoed components:

// find
const $A = React.memo(($B) => { $$$C });
// replace
const $A = React.memo(function $A($B) { $$$C });

Incompatible redux action types:

// find
interface $A extends Action { $$$B }
// replace
type $A = Action & { $$$B }

Debugging & profiling

During migration, the new react-native-devtools (supported since >0.76) can be used in order to narrow down issues.

[Rohit3523]

Nightmare coming for @diegolmello :)

[cardoso]

@Rohit3523 😂 it looks scary at first, but:

Many of the deleted files and commented out lines are in the process of being migrated and will be brought back.

It's a bit like moving all your furniture and electronics to the yard while upgrade the plumbing and wiring, then putting all of it back one by one.

This draft PR helps me track the things that are still in the "yard".

Using expo's continuous native generation will ensure a move like this won't be needed again in the very long-term.

[cardoso]

Decided to go with RN 0.77 for this experiment since the only incompatibility I ran into with 0.76 is the removal of BackHandler.removeEventListener. It's a simple change and is already being patched in most libraries. (Example: react-native-community/hooks#410).

[Rohit3523]

Version 78 is also on the way 🥲

[cardoso]

@Rohit3523 the thought also crossed my mind, but we don't need to worry about it now, since expo will handle it "later this year". Also, once migration is done it will be better to think in terms of Expo SDK versions rather than react native versions.

[Rohit3523]

Why not using expo-images instead of react-native-fast-image?

[cardoso]

@Rohit3523 I considered it, but it introduces behavioral changes. Ideally the migration wouldn't even touch the app folder to avoid introducing new bugs. After migration, expo-image can be used if it solves some problem.

[cardoso]

The experiment validated that the project can fully migrate to expo 52 taking full advantage of CNG, react native 0.77, and the new architecture. I'll close this in order to pursue incremental steps like #6143 (@diegolmello 🥇 ) and eventually a smooth migration PR.

Note: Recently, hermes / react-native added native (non-polyfilled) support for Web APIs such as WeakRef which I'm hopeful will give us ways to better manage memory consumption especially on Android, not to mention the possibility of integrating fuselage with no compromises as more Web APIs can be used unpolyfilled.