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.
Testing it right now, looks great.
nitpick:
init templates still refer to bs-platform
rescript -w do the same as rescript build -w?Also, has the -ws option been removed? The new CLI doesn’t seem to accept rescript build -with-deps -w -ws 9999
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!
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.
- looks like the
inittemplates still refer tobs-platform
Can you double check, I just tried, it does not mention bs-platform
- could
rescript -wdo the same asrescript 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
-wsoption 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.
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?
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.
is test a clean directory?
@cknitt indeed, it is a minor regression during refactoring, will fix it. (Note it does not impact correctness)
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.
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.
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.
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.
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
Yup, it is. You don’t repro on your side?
Seem it will affects us too after update. We do not use Relude directly, but it is a dependency of another library.
fixed here https://github.com/rescript-lang/rescript-compiler/pull/5089/commits/2830129c30d483d9624b1592ff62822cb12af3a5
will do a cherry pick, thanks for testing
