expo-migrate-module

Inventory every exported member first, then verify macro and core support in the checked-out expo-modules-core before editing. Migrate one semantic group at a time (naming, functions, properties, events, shared objects, records), keeping 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 source rather than trusting version numbers.

Yes. A 1.0 AsyncFunction body runs off the JS thread, while 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.

Yes, mixed mode is supported: @ExpoModule can coexist with a non-empty definition() block when the core supports merging both surfaces. Keep unsupported items like views, static shared-object members, or queue-pinned functions in the DSL until core support lands.

The expo-module.config.json entries under apple.modules are bare Swift class names with no compile-time link. Renaming a class during migration silently detaches the module, so verify the config still names every module class and that classes remain public or open.

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 checked-out core lacks required runtime hooks, since macro expansion alone does not guarantee linking or runtime invocation.