I suspect that it also works with separate compilation since 0.0.4 in which toplevel initialization bits were sanitized for WebWorker.
We were using brr.0.0.3 and after some long hours of debugging our configuration with separate compilation, we figured out that if we remove all browser-only APIs from brr the separation compilation setup finally began to work. And based on that observation we made the decision to fork.
Now looking back, it seems that it was exactly the same day when we prepared to perform a proper fork and brr was about to have a new release. (Our fork point is exactly the previous commit of the 0.0.4 preparation commit, and our first commit for the forking sits just between…)
Admittedly, I should have checked whether the newest upstream has solved our problem first but I was instead blindly executing our decision to go forward with a fork that is up-to-date with the upstream and does not contain any browser-only APIs (plus some repackaging).
I will be testing whether replacing with brr.0.0.4 solves the problem and report back the result.
I didn’t know that option exist and will definitely look into it.
I am sorry for that I have not seen it as a potential problem, and fragmenting the ecosystem around the brr’s style of JS FFI is definitely not our intention. In fact, prr is intended to purely be a stripped down and repackaged version of brr. The only other thing that we may be adding (to the repository, no to the actual codebase) without upstream consent would be tests that ensure the library works well on the platforms that we’d like it to work on.
In this regard, my understanding is that all real development will not happen at all under prr, and we will pull all upstream updates to prr. In fact we has planned to make a script for mechanizing just that.
Right now this policy is not explicitly stated on the README of prr’s repository, but is certainly our intention and implicitly conveyed by the wording of the current README. We are happy to (and probably should) revise the README and make it clearer.
If there is still a concern of unnecessary fragmentation and it is considered harmful for the ecosystem, we have no problem to take the package off opam (if that could be done and is an option). We would like to keep the fork at least internally though because we do benefit materially from this repackaging in our internal projects (especially the change to have a single toplevel module for the avoidance of name clashing).
I’m glad to know that! I will be very eager to try it out once it gets released (maybe even before that).
To add more about our situation: after enabling the separation compilation, the building time went down while the final js file’s size went up, which drastically increased the loading time on the JavaScript’s tooling side. We have mitigated most of them and have achieved a much pleasant working flow compared to before, but we were not able to make ts-jest any faster so we are now performing a separate whole program compilation to run the Jest test suite. It would be nice to be able to consolidate them.
For if sharing the numbers would be helpful to anyone, when using js_of_ocaml.4.1.0, the separate compilation results in a js bundle of about 17.1M and the whole program compilation mode results in about 2.6M. ts-jest loading time for the smaller js file is about 20~30sec but about 80~90sec for the larger one.