Possibly npx resolves to the first bin it finds?
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
I tried to upgrade my UI code (sorry it is not open source) to the rescript package, and it gave me errors everywhere about use of template literals.
It is super weird, because my other project https://github.com/wildcards-world/ui upgraded without an issue.
Here is an example error that I’m getting:
Syntax error!
/home/jasoons/Documents/code/monorepo/dapp/src/components/UI/UserUI.res:324:43
322 ┆ <UserColumnTextCenter>
323 ┆ <UserColumnText
324 ┆ head=`💰 Staked value` body={`$${totalValue.contents->FormatMone
┆ y.formatEther}`}
325 ┆ />
326 ┆ </UserColumnTextCenter>
Not sure what to do with this character.
or
Syntax error!
/home/jasoons/Documents/code/monorepo/dapp/src/components/UI/UserUI.res:240:23
238 ┆ <span className=`text-xs`> {Js.String.concat(value, `~$`)->React
┆ .string} </span>
239 ┆ </div>
240 ┆ <div className=`w-1/3 self-center`> {children} </div>
241 ┆ </div>
242 ┆ }
Did you forget a `,` here?
I’ve spent a long time trying to pin-point the issue. It isn’t a big problem for me (I can stay on bs-platform 9.0.1 without stress), I’m more posting in-case others have the same issue.
I seem to have found the issue. I use the $ symbol often in my code (it is a finance app), and that causes issues with template literals.
Converting $ to \$ does the trick.
Can you post the original code you were trying to convert? I’ll take a deeper look and fix the problem.
Hi Maxim. I’ve narrowed it down. The error happens when a string literal ends with a $
let thisIsFine = `$something`
let thisIsAlsoFine = `fine\$`
let isThisFine = `notFine$`
(In playground: https://rescript-lang.org/try?code=DYUwLgBGAWCWDOBJeAxWA7EEC8EAGAJPAPYC24c6A5ngFCiQwLICCwJamO+AZhiAB0CdBhAQAVOKn7c86YmE4hhQA)
This code worked in bs-platform@9.0.1
Ok, digging deeper into the issue:
Bellow code shows dollarAmountInt as an unused variable (warning 27):
@react.component
let make = (~dollarAmountInt) => {
`$${dollarAmountInt}`->React.string
}
In fact, more than that, the following code compiles (only with the same warning as above):
@react.component
let make = (~dollarAmountInt) => {
`$${aNonExistantVariableWhyDoICompile}`->React.string
}
The way to make the above work as expected is to escape the $ with a \ in front:
@react.component
let make = (~dollarAmountInt) => {
`\$${dollarAmountInt}`->React.string
}
(Once again, this seems to be a regression from bs-platform@9.0.1 - none of those issues exist if switching to that version in the playground)
Thanks for the report, investigating.
@JasoonS thanks for catching this! Sorry for the trouble
Submitted a fix here: https://github.com/rescript-lang/syntax/pull/394. Will see if we can get this released.
Hi all, thanks for all people who help testing. We are very close to a final release.
Note there is an issue observed when both the old bs-platform and rescript installed: we kept the old CLI bsb to avoid disruptive changes, but there is a consequence due to that npm do the npm link, so it is possible that the old bsb would shadow the new bsb, it may cause some unexpected behaviors.
Since the build command just run once on the toplevel package, so we are considering removing bsb in the new release, so for new packages people would just type rescript. Would it bring some unexpected behavior?
Thanks!
Amazing, thank you @Hongbo
Since it is completely new package that users would have had to manually decide to install I think it is fair that it is expected that they manually have to go through their scripts and replace their usage of bsc.
Rather make them do that IMO than the chance that people get stuck and confused at weird behavior because they forgot to remove bs-platform. But just my opinion.
