expo-migrate-module

Inventory every exported member as the JS contract, verify macro and core support in the checked-out expo-modules-core, then migrate one semantic group at a time: naming, functions, properties, events, shared objects, records. Keep unsupported members in the 1.0 definition() block as mixed mode.

Use expo 57.0.21 or newer; earlier 57.x versions compile the macros but lack many 2.0 features. The macros are experimental in SDK 57 with the official beta in SDK 58, so verify the checked-out expo-modules-core rather than trusting version numbers.

No, views are not covered by 2.0 yet. Keep UIKit View, Prop, view Events, and OnViewDidUpdateProps entries on the 1.0 DSL; a module with views migrates its non-view members and keeps the view in mixed mode.

A 1.0 AsyncFunction ran off the JS thread, but a 2.0 async @JS member starts on the JS thread and leaves only at the first await. A body that never awaits blocks the JS thread; fix it with @JS(.concurrent) or restructure onto Swift Concurrency.

Only if the checked-out core declares the constructor:-labeled shared-object decoration hook; the prototype: overload shipped earlier, so static members can expand and then fail to link. Otherwise keep StaticFunction and StaticAsyncFunction entries in the 1.0 Class block.

Do not use it for creating a new module, general Expo SDK upgrades, or Android/Kotlin migrations, which stay on the 1.0 DSL. Also avoid it when the installed core lacks required runtime hooks and mixed mode cannot preserve the JS contract.