Playground 2021 #4947
Playground 2021 #4947
Conversation
ryyppy
force-pushed
the
playground-2021
branch
from
5b37fd5 to
cc3e314
Compare
jscomp/refmt/jsoo_refmt_main.ml
Outdated
|
|
||
| module Converter = Refmt_api.Migrate_parsetree.Convert(Refmt_api.Migrate_parsetree.OCaml_404)(Refmt_api.Migrate_parsetree.OCaml_406) |
There was a problem hiding this comment.
Why is this using the ocaml 4.04 ast ?
There was a problem hiding this comment.
I think this was a requirement of Reason's 3.6 api back then.
CONTRIBUTING.md
Outdated
|
|
||
| We actually ship a bytecode version of `js_of_ocaml`, so you actually don't need to install any third party dependencies. This is usually for basic usage if you don't care about the compilation speed or a fast feedback loop (e.g. CI). | ||
|
|
||
| For faster compilation times, we recommend to install a proper `jsoo` executable: | ||
|
|
There was a problem hiding this comment.
This is a one time effort, I suggest we just use the vendored bytecode to avoid opam toolchain.
To share a similar story: I used ocaml-tree/tree-sitter-ocaml.wasm which is much slower than the native in the code generation, but it is fine, the lower maintainance overhead is a bigger win
It is also easy to reproduce the build without worrying about which version of jsoo is used
IIUC, if we don't need jsoo (use the vendored bytecode instead), we don't need document opam either, is it correct?
There was a problem hiding this comment.
it's mostly for those ppl who need to work on the bundle (like me). The development feedback loop (when working locally) is around 3min slower when compiling with the bytecode version.
Using the natively built version of jsoo is around 30 seconds, which is already really slow, but way better than 3 minutes.
The bytecode build is fine for processes like CI (and also way better due to zero-deps).
CONTRIBUTING.md
Outdated
|
|
||
| The entry point of the JSOO bundle is located in `jscomp/main/jsoo_main.ml` and the script for running JSOO can be found in `scripts/repl.js`. A full clean build can be done like this: | ||
| The entry point of the JSOO bundle is located in `jscomp/main/jsoo_refmt_main.ml` and the script for running JSOO can be found in `scripts/repl.js`. A full clean build can be done like this: | ||
|
|
There was a problem hiding this comment.
I just removed the js part of refmt a couple of weeks ago (i.e, js_refmt_main.ml).
Since the playground is not essential part of keep making reason working, I am not convinced to add it back.
- For people who want to learn the conversion from reason to rescript syntax, they can use the CLI tools
npx bsc -format xx.re
it will print the rescript syntax
- remove the reason syntax for the playground not only bring less maintainance overhead, it makes the playground load faster. On a slow network (my case), it takes a while to load the playground
There was a problem hiding this comment.
We still have a bunch of production users that are still stuck on ReasonML syntax (although they want to upgrade), so they heavily rely on the playground functionality to convert between ReScript and Reason snippets.
^ The toggle seen here uses the vendored refmt code, which is the exact same version as the refmt we ship in the compiler toolchain still.
The last blocking factors for some of our production users are "local open" support (some still want infix operators, but I think that is less pressing than local open).
I'd suggest to remove Reason support on the playground when we are 100% sure that we are not interfering with our users' workflows. Maybe we should open a topic on the forum discussing this?
|
Note to myself: I fricking hate rebasing. I never get this right... i will start creating PRs for each consecutive playground bundle release, because keeping everything on this branch is just terrible. |
Newest playground state based off the original work in #4518