What do the spec file and CodeGen do in migration?

WHAT THIS TESTS: Knowing how the new architecture enforces a typed contract between JavaScript and native UI components and where code generation fits in the build.

A GOOD ANSWER COVERS: The spec file, named with the NativeComponent suffix, is a typed declaration of the component's public surface: its props, their types, supported commands, and events. Written in TypeScript or Flow, it is the single source of truth for the interface. CodeGen is a build-time tool that parses these spec files and generates the boilerplate that wires the component into Fabric: type-safe C++ and platform-native classes plus the JavaScript bindings. Because generation happens at build time, a prop typed as a number in the spec but provided differently produces a compile-time error instead of a runtime crash. During migration you author the spec, register the component for CodeGen, and let it produce the glue rather than hand-writing it.

COMMON WRONG ANSWERS: Describing the spec as runtime configuration read by the app. Believing CodeGen runs on device. Thinking you still hand-write the native-to-JS bindings. Confusing the spec file with the component's implementation; it declares the interface, not the rendering logic.

LIKELY FOLLOW-UPS: Where generated files live, how commands differ from props, how this enables synchronous type safety, and what changes for the native implementation class.

ONE CONCRETE EXAMPLE: Migrating a map view, you write MapViewNativeComponent.ts declaring props like region and zoomEnabled and an onRegionChange event. CodeGen generates the Fabric component descriptor and JS bindings; passing a string where region expects an object now fails the build instead of crashing when the map mounts.