[Playground] Replace opam with esy, include reason-react in CI workflow

[jchavarri]

@bobzhang I noticed that GH actions are not enabled in the repo, actions stopped running a few months ago.

This PR disables the main GH workflow so that actions can be enabled again. Please let me know if this should be taken to a different PR.

---

Playground changes:

• Replaces opam with esy for playground as it's much more easily cacheable in CI (and probably easier to setup in local development, as esy was already used in the repo)
• Changes CI playground workflow to include reason-react in resulting bundle
• Adds CI test to check that reason-react cmis are properly included
• Moves repl.js from scripts to playground
• Upgrades main README documentation to reflect latest changes in cmis/cmjs and replacement of opam with esy cc @ryyppy

[jchavarri]

Here's the link to the run from latest commit https://github.com/jchavarri/bucklescript/actions/runs/99490190.

[bobzhang]

what's the benefit for such change?

[cristianoc]

I have spent quite a lot of time optimizing esy builds on azure.
It was complex, with 2 kinds of cache.
Never got it faster than 2X slower than before.

The reason I have considered it, is to support Windows.
But overall Windows is incredibly slow (5X slower or something), very fiddly, and breaks from time to time.
I have not had the time yet, but when I do, I'll go back to opam. Much simpler.

[cristianoc]

I would like to drop Azure too, and go back to circleci now that Windows is supported.

[cristianoc]

I don't have dependencies, so the appeal of dealing with dependencies nicely does not apply.

[ryyppy]

I've already chatted with @jchavarri regarding this workflow

There are following things I want to chime into this discussion:

• The github workflows are solely for simplicity, accessibility and visibility reasons to build and upload the playground JS artifacts on a centralized place. It's not mission critical that these builds are fast... it should be run once when there is a new version tag, just so we have access to the newest playground... if a build takes like a day, as long as it is reliable, it can even take like one day to build and I wouldn't care
• Especially with the esy thing, I'd agree that we don't want to have it back in our CI pipelines, since it's really hard to maintain if you don't know the ins- and outs of the tool. On that note, we should really consider writing some CONTRIBUTING guidelines on what engineering practises BuckleScript follows (no esy / huge dependencies, clear rules how CI works,...). That way, it's easier for contributors to not spend a whole lot of time building a solution which won't be merged anyways.

We really need this automatic playground workflow running to finally get to start with the actual playground UI work. What can @jchavarri and I do to make that happen?

[bobzhang]

I was asking the benefit of switching the package manager, will get back to you later

[jchavarri]

The main benefit was to reduce CI build times. The story for caching opam in CI is not there yet (I'm sure it'll be on day) but right now, the recommended GH action to setup OCaml and opam creates the switch and builds the compiler for every CI run. Just this step takes ~12min in macOS, 7 to build the compiler and 5 to build jsoo:

esy can cache not only dependencies but also the compiler artifacts, so you only have to "pay time" for downloading esy. I think that's a pretty significant upside.

This pipeline build time is now around 12 min, most of which is spent building the BuckleScript OCaml fork.

if a build takes like a day, as long as it is reliable, it can even take like one day to build and I wouldn't care

@ryyppy I agree... once the pipeline has been set up and you don't have to touch it. But you will always have to touch it as things break etc. Imagine that for every change you do you have to wait one day, in the end you (or anyone else) would not maintain it anymore after it breaks. And @bobzhang would (understandably) just disable the pipeline at some point.

Never got it faster than 2X slower than before.

@cristianoc I agree that setting up esy in CI can be quite complex, although things have improved a lot lately (mostly speaking from the progress in hello-reason repo, which I consider state of the art). This 2X hit sounds strange to me. I have seen esy pipelines run in 30 seconds so if there's anything esy does right imo is speed up CI builds by leveraging caching 🤔

[bobzhang]

How about checking in a bytecode version of JSOO then we are all set? Javier Chávarri <[email protected]>于2020年5月10日 周日下午5:17写道：

The main benefit was to reduce CI build times. The story for caching opam in CI is not there yet (I'm sure it'll be on day) but right now, the recommended GH action <https://github.com/avsm/setup-ocaml/> to setup OCaml and opam creates the switch and builds the compiler for every CI run. Just this step (setting up a traditional OCaml toolchain) takes ~10min in macOS. esy can cache not only dependencies but also the compiler artifacts, so you only have to "pay time" for downloading esy. I think that's a pretty significant upside. This pipeline build time is now around 12 min, most of which is spent building the BuckleScript OCaml fork. if a build takes like a day, as long as it is reliable, it can even take like one day to build and I wouldn't care @ryyppy <https://github.com/ryyppy> I agree... once the pipeline has been set up and you don't have to touch it. But you will always have to touch it as things break etc. Imagine that for every change you do you have to wait one day, in the end you (or anyone else) would not maintain it anymore after it breaks. And @bobzhang <https://github.com/bobzhang> would (understandably) just disable the pipeline at some point. Never got it faster than 2X slower than before. @cristianoc <https://github.com/cristianoc> I agree that setting up esy in CI can be quite complex, although things have improved a lot lately (mostly speaking from the hello-reason which I consider state of the art). This 2X hit sounds strange to me. I have seen esy pipelines run in 30 seconds <https://github.com/esy-ocaml/hello-reason/runs/615679710> so if there's anything esy does right imo is speed up CI builds by leveraging caching 🤔 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMK7XU3SIYGAQBVZUSYLRQZWK3ANCNFSM4M4QOOBA> .

-- Regards -- Hongbo Zhang

[jchavarri]

@bobzhang not sure I understand. You would still need ocamlc.opt to run it no?

[bobzhang]

No , in that case, you only need camlrun which is already vendored Javier Chávarri <[email protected]>于2020年5月10日 周日下午5:48写道：

@bobzhang <https://github.com/bobzhang> not sure I understand. You would still need ocamlc.opt to run it no? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMKYBBPWH6CGLWUUJIE3RQZZ6TANCNFSM4M4QOOBA> .

-- Regards -- Hongbo Zhang

[jchavarri]

Sounds good, will investigate.

[bobzhang]

Ocaml bytecode is portable and cross platform once we have one version checked in , we don’t need jump all those hooks to get jsoo. Note jsoo recently made it self contained (no js runtime deps), so it seems worth exploring Javier Chávarri <[email protected]>于2020年5月10日 周日下午5:57写道：

Sounds good, will investigate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMK2IFKLTLSLFTQRE3V3RQZ3CNANCNFSM4M4QOOBA> .

-- Regards -- Hongbo Zhang

[bobzhang]

see #4372, can you confirm that it works on your machine?

[bobzhang]

with #4372 landed, the CI should be pretty easy to land. I am thinking that can CI be coupled from the core repo, maybe nightly build for JS playground?

[jchavarri]

Thanks @bobzhang ! #4372 looks great

[bobzhang]

Now it should give you a playground in a couple of minutes -- we can enable it for each commit, the main concern is that it may introduce lots of diffs

…

On Mon, May 11, 2020 at 5:10 PM Javier Chávarri ***@***.***> wrote: Thanks @bobzhang <https://github.com/bobzhang> ! #4372 <#4372> looks great — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMK5YXZWB5YWBTBWNXLTRQ66JHANCNFSM4M4QOOBA> .

-- Regards -- Hongbo Zhang

[jchavarri]

we don't need to check in git the resulting js no?

[bobzhang]

@jchavarri I am thinking that we do a daily job (instead of per each commit) to sync up the js version of the compiler, do you think it is a good idea? If so, do you think can this be done in a separate repo (with just js files)?