PureScript FFI boundary design when migrating JavaScript modules incrementally
0 reputation · 27 Oct 2021, 10:14 UTC
Incremental JavaScript-to-PureScript migration with a shared FFI boundary
I am migrating a small browser application from plain JavaScript to PureScript one module at a time, and both sides must keep running together in production during the transition. The plan is to wrap the remaining JavaScript modules behind foreign import declarations so new PureScript code can call them, while legacy code paths still call the same JavaScript directly.
The unresolved decision is how to keep the FFI type declarations trustworthy while the JavaScript side is still changing. The compiler does not check that a foreign import signature matches the actual JavaScript function, so a drift between the two would only surface at runtime. I also need to decide whether effectful JavaScript calls should be typed as Effect immediately or wrapped in a narrower custom effect row during the migration.
Assume PureScript 0.15.x with spago builds, and that the output is bundled for the browser alongside the legacy bundle.
- Is there an established pattern for versioning or validating FFI declarations against the JavaScript they wrap during a gradual migration?
- Should migrated modules expose
Effectdirectly, or a constrained effect row, to avoid locking in the wrong boundary early? - Are there pitfalls when the same JavaScript module is imported both through the FFI and by legacy code in the same bundle?