PureScript FFI and JavaScript module formats: verifying runtime representations across compiler versions

PureScript compiles to JavaScript and exposes host functions through foreign import, but the FFI boundary is untyped: PureScript's erased types become plain objects at runtime, and JavaScript consumers cannot rely on compile-time guarantees. The compiler can emit different JavaScript module formats, such as CommonJS and ES modules, which determines how Node.js, bundlers, and browser loaders resolve the generated output. Because default module formats and code-generation targets have shifted across compiler releases, build tooling pinned to an older PureScript version may produce output that a newer host runtime or bundler configuration no longer consumes as expected.

The unresolved behavior centers on runtime representation. Records and data constructors are documented as plain objects, yet newtype unwrapping and recursive types can produce layouts that surprise FFI authors. The Foreign library offers readers like readNumber, but deciding when to validate versus trust at the boundary remains a developer responsibility rather than a compiler-enforced rule.

For a project targeting both Node.js and a browser bundler, what is the safest way to verify that a PureScript module's generated exports match the expected runtime representation across compiler versions? Should validation live inside the PureScript FFI wrapper using Foreign readers, or at the JavaScript import site, and how do changing module-format defaults affect that choice?