Hi all,
ReScript 9.0.0 is available for testing, the changes are listed here.
The syntax improvement is listed here.
Together, we also released @rescript/std@9.0.0 as an alternate light weight standard library for advanced users.
Test and feedback is welcome! – Hongbo
It got two of my biggest bundles to drop from 108kb to 106kb, and 96kb to 95kb. A small but very welcome improvement!
Would be nice if stdlib has its own changelogs, as I would watch that more closely than the bs-platform language/compiler notes
upgrading broke my jest tests. I suspect it has to do with the mjs modules.
Note we only changed the extension for standard library es6 modules from .js to .mjs.
It does not change the default setting for user land libraries.
So it should only introduce visible changes if you refer the standard library js file name directly
I fixed it by adding mjs to the transform in jest.config.js
transform: {
'^.+\\.(js|mjs)$': './jest-transform.js',
},
We upgraded to 9 for a single feature not mentioned in the post - simplified exotic poly-variants. Probably worth mentioning as it greatly simplifies js interop. https://github.com/rescript-lang/syntax/pull/228
I think this does not work correctly. All bs-platform specific imports now import the .mjs files in my project. This breaks compatibility with React-Native, so this is a show stopper for us (and all other React-Native apps I suppose).
See: https://github.com/facebook/metro/issues/535
Would it be possible to make the mjs import be configurable (preferably defaulting to js because it breaks most projects that depend on webpack or metro/react-native).
did you define any suffix in your bsconfig?
Yes, bs.js. (my files are bs.js, but the imports from bs-platform are .mjs)
Can you use commonjs output format? The mjs files should only be imported when using ES6 
Nope. Not possible for us. (We rely on a number of es6 features). Mjs and es6 support are two separate things, React-Native does support all the es6 features but not the mjs extension.
I actually had the same issue for mjs - but with Jest. I fixed it by adding,
transform: { "\\.m?[jt]sx?$": "babel-jest" }
@jfrolich take a look at this - https://facebook.github.io/metro/docs/configuration#sourceexts
It’s also not great when building js-libs with ReScript. Now any project that directly or indirectly depends on the lib needs to configure mjs support which in most cases is not supported by default.
This is probably not a unique problem just for ReScript… how do other JS libs deal with that in React-Native? What is the most graceful setting that is both backwards / and future compatible?
I kinda lost sight of the whole situation ever since Node ppl started to talk about ES6-modules-but-not-really-ES6-modules (aka faux es modules?)
I didn’t really see the mjs extension being used anywhere yet. It’s still far from mainstream, and supported yet.
What’s the rationale behind this? What are the downsides of shipping modules with the js extension?
I can imagine that this allows for easier serving of web modules without bundling, but shouldn’t that be an optional configuration until its broadly supported? Breaking a lot of peoples tooling (including indirect consumers) is a pretty bad user experience.
It’s all discussed in github:
The problem with using .js for ES6 files in NodeJS is that without module: true in package.json some tooling breaks. This would need to be in the bs-platform package file which would then break anyone using CJS compilation.
This problem has caused me to compile to both CJS and ES6 in the project I work on; CJS for the tooling and ES6 for bundling. This in turn causes problems with binding to a default export, which is done differently between the two compile modes.
Maybe we need an extra ES6 compile mode? Put the default back to .js, and add something new for people like me who need .mjs?
@jacobp100 Thanks for the detailed report and repo!
I think we need to discuss this in more detail when Bob’s back, since this now opens up the question if this is going to be a breaking change with a feature follow up to work around the limitations, or a feature that needs to be rolled back.
For now we’ll probably add a note to the blog post’s breaking changes list and check back later on how to proceed?