expo-migrate-module

Inventory every exported member first, then migrate one semantic group at a time: module naming, functions, properties, events, shared objects, and records. Verify macro and core support in the checked-out expo-modules-core before each group, and keep unsupported members in the 1.0 definition() block.

The 2.0 macros require expo 57.0.7 or newer. Check the installed version in package.json or with npm ls expo before editing, and still verify the checked-out source because macro and core support varies within 57.x releases.

Yes, mixed mode is supported when the paired core merges both surfaces. Keep unsupported entries like views, queue-pinned functions, or sync events in definition(), avoid duplicate names across macro and DSL registrations, and delete definition() only when it is empty.

The default @Event wire name strips a leading 'on' and decapitalizes the remainder, so onProgress becomes progress. Pass the original wire name explicitly, such as @Event("onProgress"), to preserve the existing JS listener contract.

Do not migrate queue-pinned functions or blocking bodies as-is, because 2.0 async members start on the JS actor instead of a background queue. Restructure with Swift Concurrency or dispatch to the original queue inside a checked continuation, or keep the function on the DSL.

No, the scope is limited to existing Apple/Swift modules. Kotlin stays on the 1.0 DSL unless explicitly requested, and the workflow is not intended for creating new modules or general Expo SDK upgrades.