Understand native build compatibility/effort

[andywhite37]

It would be interesting to see what it would take to build relude natively, even if we don't have a specific use case right now. We know there are some compatibility issues now, but it would be interesting to understand exactly what those are.

Somewhat-known issues:

• bs-abstract
  • I'm not sure if anyone has attempted to build bs-abstract natively, and what issues might be there.
  • If there are issues, we can probably submit PRs to address them in bs-abstract?
• Belt
  • I believe Belt is supposed to work with native builds, but not sure if you need to use something like this: https://github.com/jaredly/belt
  • We could endeavor to eliminate all usage of Belt, but not sure if it's worth the immediate effort if it can compile natively
• Js modules
  • E.g. Js.Json, Js.Promise, etc.
  • Not sure what the story is for making these work natively (if there is a story at all)
  • We could isolate these things into sub-packages that we only compile with Bucklescript, or move it all out into a separate lib like relude-js, but I don't want to break up the core too much if we don't have to.
• Std lib usage
  • I don't think this is a problem in native, but not sure.
  • Maybe we should try to eliminate usage of the std lib?
• Jest
  • I wonder if there's any way to make unit tests compatible with both Jest and Rely (or any other test frameworks), like a common API that be compiled to both targets?

[mlms13]

Just linking this up... Risto-Stevcev/bs-abstract#13

[mlms13]

A note on Belt... I'm not sure how much the jaredly/Belt fork automated the changes and how much those changes were done by hand, but there are definitely changes. Even the AVL tree implementation (which is used by Belt.Map) seems to have Js.null and [@bs.deriving abstract] in it. It'll take some effort, but I vote we find or write pure Reason alternatives to the functions in Belt once we get around to this.