[ANN] ReScript 9.1.1 call for testing (second beta release)

[Hongbo]

Hi all,

Following the first beta release, we have created a new beta version to help you adapt your software to the new features ahead of the release. Your feedback is critical to help us to improve the user experience.

This release fixes several regressions reported during first beta testing.

One noticeable user experience enhancement is that we’ve unified rescript build and rescript build -with-deps (aka the equivalent of bsb and bsb -make-world) into the single command rescript. Upon calling rescript, it’ll figure out the unbuilt dependencies automatically, at almost zero cost.

So for most users, the only command to memorize is effectively just rescript! This achieves what we’ve always wanted, while keeping a performance level we’re satisfied with.

We will mark this release as a stable release if no serious regressions are found, thanks!

======== below is the first beta release for reference =======

We’re finalizing the transfer of our npm package under the new name rescript. This is still a beta, so please report any problem.

The old package bs-platform will still exist, and we’ve carried the old binaries (bsc, bsb) over to the new rescript package for compatibility.

Along with these old binaries, we’re adding a new one: rescript.

npm i rescript
npx rescript init
npx rescript build

The new rescript CLI adopts the subcommand approach so that it is more extensible in the future, it is pretty easy to learn those options:

npx rescript -h
npx rescript format -h

Thanks to this approach and npx, commands like npx rescript format should work out of box, with zero installation, even on Windows!

The new CLI is not finalized yet, your feedback is welcome!

A list of changes are available here: https://github.com/rescript-lang/rescript-compiler/blob/master/Changes.md#91

[cknitt]

Hi Bob, thanks a lot! I retested the affected project now that https://github.com/rescript-lang/rescript-compiler/issues/5071 is fixed, and everything compiles fine now.

We will mark this release as a stable release if no serious regressions are found, thanks!

I would suggest to wait until the VS Code plugin works with this version, see https://github.com/rescript-lang/rescript-vscode/issues/104.

[chenglou]

Thanks @cknitt. I’ve made a small new release of the editor plugin. Things should work now.

[bloodyowl]

Testing it right now, looks great.

nitpick:

1. looks like the init templates still refer to bs-platform
2. could rescript -w do the same as rescript build -w?

[bloodyowl]

Also, has the -ws option been removed? The new CLI doesn’t seem to accept rescript build -with-deps -w -ws 9999

[supriyo]

Hi Bob,

I think there was a change with how object externals are compiled to JS.

Take this example using 9.0.1 https://rescript-lang.org/try?code=AINwhgNgBApgHgFxgJwHaSgEwPYGMCuAtjKggFxQDeAdNQL5QC8UARDgcaSwFDcQwIouMKnABnJljxESCANosAjvhQBPAMox+uBNmQsAugAoWAYmGiwYlgEpuQA

When compiling with rescript@9.1.1, the javascript output is:

// Generated by ReScript, PLEASE EDIT WITH CARE

import * as Curry from "../node_modules/rescript/lib/es6/curry.js";

var canvas = Curry._1(document.querySelector, "#canvas");

This causes a runtime error :
Uncaught TypeError: 'querySelector' called on an object that does not implement interface Document.

It can be fixed by uncurrying the call site of querySelector, but I’m not sure if the change was intentional. I couldn’t see anything obvious in the release notes or pull requests/issues.

Let me know if I missed something or want me to setup an example repo.

The release looks great otherwise. Thanks!

[Hongbo]

Hi, this is considered a bug fix, previously

let h = { "x" : (a,b) => a + b }
let u = h ["x"](1,2)

This is a perfectly valid code while it doesn’t compile.
After this release,

let h = {"curriedx" : (a,b) => a + b ,"uncurried" : (.a,b) => a + b}
let u = h ["curriedx"](1,2) + h["uncurried"](.1,2) 

should compile. If you look at your bindings, it is indeed something incorrect, since querySelector is an uncurried call.

[Hongbo]

1. looks like the init templates still refer to bs-platform

Can you double check, I just tried, it does not mention bs-platform

2. could rescript -w do the same as rescript build -w

We don’t want to complicate the command line parsing too much, rescript is treated specially, otherwise all flags should go through subcommands

Also, has the -ws option been removed?

This is not intentional, we will add it back. It is interesting to see you use that flag, would you mind share your use case?

Note the new CLI is mostly written in JS(except latency critical path: the build subcommand), so that the contribution should be easier, contributions are welcome.

[cknitt]

I tested another project with ReScript 9.1.1. Everything compiled fine. In the compiler output I noticed that e.g.

import * as UserInfo$CommonBase from "common-base/src/auth/UserInfo.bs.js";

was changed to

import * as UserInfo$negCommonBase from "common-base/src/auth/UserInfo.bs.js";

What is the reason for the neg prefix?

[bloodyowl]

Sure, I’ll try to create a PR tomorrow. The use case is like what’s found in the https://github.com/bloodyowl/rescript-react-starter-kit repo. I make the dev server wait for the compiler to end to trigger a rebuild.

[bloodyowl]

Possibly npx resolves to the first bin it finds?

[Hongbo]

is test a clean directory?

[Hongbo]

@cknitt indeed, it is a minor regression during refactoring, will fix it. (Note it does not impact correctness)

[johnmegahan]

The removal of the Marshal module in this version caused any dependencies using the bisect_ppx, which includes Relude, to not compile. At the moment we’re stuck in .re format anyways because we make heavy use of let bindings but we were writing new code in .res format when we could. This wasn’t documented but reading through the commits it seems pretty intentional, so we’ll just stick at 9.0.x for a while since we use Relude extensively, but just a heads up.

[Hongbo]

Marshal was never supported in the beginning so I thought removing it was an internal cleanup.

IIUC, biscet-ppx should be used at most as a dev dependency so it should still work in theory with relude?

In general, ppx would pull in a whole universe of dependencies with out care, it is strongly recommended to avoid it or using it just as a dev dependency. Note not many languages encourage users to write a compiler plugin, ocaml is probably one of the very few. It makes upgrade a very painful experience.

[johnmegahan]

Yeah, I understand. I left a comment about this on an issue in Relude that is discussing ways to remove it from the dependencies. We may do a temporary internal fork as well to keep our progress moving forward.

[johnmegahan]

@Hongbo

Marshal was never supported in the beginning so I thought removing it was an internal cleanup.

This is kind of a separate thing, but could we possibly get a flag to turn on warnings from the compiler when we’re using an unsupported OCaml module?

There wasn’t a lot of learning material when we started using ReScript a couple of years ago, so we repurposed OCaml learning material. And the vast majority of our code is not Frontend/React code. So I’m sure we’re using some OCaml modules that you consider unsupported. If we could somehow know what those are I think it’d make everyone’s work lives a bit easier.

[Hongbo]

Yes, that’s what we are going to do.
For example, we added a warning to Format usage.
The Marshal is a bit special, since none of functions in Marshal is supported, if you run it, you would get an runtime exception, but it is noted, thanks for your suggestions

[bloodyowl]

Yup, it is. You don’t repro on your side?

[vdanchenkov]

Seem it will affects us too after update. We do not use Relude directly, but it is a dependency of another library.