RECENTLY, the BuckleScript project was renamed to ReScript. This apparently caused a lot of questions and confusion. So I will try to answer those questions from the point of view of actual use cases. The most important question: what does ReScript mean to me (or my project)?
I am a BuckleScript user with ReasonML syntax
That is, you are using the BuckleScript compiler (now called ReScript) from the npm package bs-platform
. And you are using ReasonML syntax (.re
, .rei
files) that is supported out of the box.
In this case the recommendation from the ReScript team is to migrate to ReScript syntax. They provide a migration script to do so. I won't delve into the justifications for the new syntax--the team has covered that extensively--but suffice to say the migration should be easy and well-supported, and a one-time effort.
Of course, that's just the recommendation; you don't actually need to migrate if you don't want to. For the foreseeable future, ReScript (the compiler) will continue to ship with ReasonML (v3.6) syntax support out of the box so your project can stay unaffected. But presumably at some point in the distant future, they will stop shipping that syntax. At that point you have other options if you want to keep using ReasonML syntax with ReScript, but none that are supported or recommended by the team.
I am a BuckleScript user with OCaml syntax
In this case you don't actually need to do anything; OCaml syntax is not going away.
The one caveat to this is that OCaml syntax won't be an officially promoted (or documented) part of the ReScript platform. So anyone using it presumably knows what they are doing and are capable of translating back the ReScript documentation to OCaml for themselves.
You could of course consider migrating to ReScript syntax; but strictly speaking there is no need, so purely your decision.
I am a ReasonML user with esy/pesy/etc.
In that case you also don't need to do anything; ReasonML is a separate and ongoing project, and so are esy and pesy.
I am an OCaml user with dune/opam/esy/etc.
In that case you also don't need to do anything; the ReScript changes don't affect you at all.
I wanted to compile OCaml to both native and JavaScript
In that case you can (and always could) use the well-established project Js_of_ocaml (and even the Ocsigen/Eliom framework, which is a truly full-stack OCaml solution).
I wanted to compile OCaml to both native and JavaScript using BuckleScript/ReScript
Trust me; you don't want to do that. I've done a proof of concept of what it would look like, and the effort and the coordination of different tools and conventions required across the native and BuckleScript compilers and toolchains, is a large amount of effort with unclear payoff. It's unfortunate, but nothing is perfect and this particular combination is just not viable.
Of course, you could always--and still can--have fullstack ReScript by targeting Node.js as well as the browser. There may be even more exotic JavaScript targets that are capable of running ReScript output JS--in the past I've created a Windows Scripting Host script!
I wanted to compile to native and JavaScript using bsb-native
As far as I know, bsb-native is an abandoned project. You are of course welcome to fork and work on it!
I want to do something else and the ReScript change affected me
I would be interested to hear about how that happened.
Top comments (4)
Agreed! At Dark we sunk a bunch of resources into that, and it didn't get us anything of value.
Very well written article!
Maybe it's worth mentioning that you can achieve fullstack Rescript by having your backend code compiled by rescript to JS that you then run on Node.js? I think this is a very viable solution to fullstack Rescript going forward.
Thanks! And good point–I've updated the post.
Worth noting that reasonml projects which have reason-react as a dep dont work with @rescript/react in your dependencies. See issue #6 on rescript-react repo.