[ANN] ReScript 9.1 released!

This release contains quite a few exciting improvements, that many have probably been waiting for =)



I removed bs-platform and installed rescript.

Now I’m getting this type of error

rescript: [279/444] src/turboroof/TrLogin-Sobras.cmi
[0] FAILED: src/turboroof/TrLogin-Sobras.cmi
[0]   We've found a bug for you!
[0]   /code/sobras/src/turboroof/TrLogin.resi
[0]   It's possible that your build is stale.
[0]   Try to clean the artifacts and build again?
[0]   Here's the original error message
[0]   The files /code/sobras/node_modules/rescript/darwin/bsc.exe
[0]   and /code/sobras/node_modules/@rescript/react/lib/ocaml/react.cmi
[0]   make inconsistent assumptions over interface Pervasives

Could it be a dependency or ppx that I’m using?


The error went away after removing node_modules and running npm install again


Npm in 2021 ¯\_(ツ)_/¯


I replaced bs-platform with rescript in my project. Everything is fine.
Love object spread and improvements on poly variants.
Thank you for the hard work of the ReScript team.

I would like to know if poly variant for number will support float type like
#1.1 :> float

Thank you.

1 Like

Do you have a concrete use case for that #1.1? note in floating numbers 1.1 is not necessarily 1.1


Hi @Hongbo

I don’t have a concrete use case for production projects.
But i once code like it in TypeScript for fun. So i am just wondering if i could do the same in ReScript in future.

type TinyRadius = 1.11 | 2.21 | 3.31

function drawTinyCircle(tr: TinyRadius) {

I am aware that floating numbers has an issue:

type GoldenRatio = 1.61803398874989484820 

let grn : GoldenRatio = 1.6180339887498948482033333 // TS doesn't complain

Thanks & Regards,

Nice release!
I’ve a question about rescript cli, is there any reason behind not using double dash for word flags? i.e
rescritp format --all . the previous cli was based on ocamlc so that was legacy. Most CLIs I work with use this standard (double dash for words, single dash for chars).


Thanks a lot for your great work! :slight_smile:

One remark regarding :>: Unlike an external defined using %identity, a function defined using :> won’t be optimized away across module boundaries.


type t = [#1 | #3 | #5]

let toString1 = (arg: t) => (arg :> int)

external toString2: t => int = "%identity"




import * as A from "./A.bs.js";



YMMV, but in cases like this I’d probably reach for something more semantic, i.e.,

enum TinyRadius {
    s = 1.11,
    m = 2.21,
    l = 3.31

Even though TinyRadius.m is verbose, and I definitely prefer "foo" | "bar" for strings. Anyway, in ReScript I’d probably to with:

type tinyRadius = | Sm | Md | Lg

let drawTinyCircle = (tr: tiniRadius) => {
  let radius = switch tr {
  | Sm => 1.11
  | Md => 2.21
  | Lg => 3.31
  // ...

I am working on a static site which might cycle between periods of having a full time maintainer and no maintainer, so it may be hard to upgrade ReScript versions frequently. What upgrade cadence do you recommend for such a project? Yearly or more frequent?

1 Like

If you stay on our recommended paths then the upgraded shouldn’t take more than a few mins to an hour generally speaking. For a big production budget it might take longer. We do upgrades ourselves internally and on side projects to get a reasonable estimate.

If you try to jump several versions at once, it’s possible that it’s harder since you can’t take advantages of the semi-automatic codemod-style upgrades that these incremental upgrades offer each time.

If it’s just a static site then there shouldn’t be such concern in the first place. Again, make sure you stay on the recommended paths.

1 Like

The upgrading should be easy in theory.

The reality is more difficult due to the fact that your dependencies may have ppx involved.

For your project, if you have less manpower, do a sanity check to see if your dependency chain has ppxes involved, try to avoid them if possible. If your project is ppx free, upgrade should be mostly fix deprecation warnings