Hello everyone!
As you may already know, we had our ReScript Retreat 2024 event from 22-25th of May in Vienna to work together in person and sync up on our processes.
There we discussed our goals and ambitions for the next major release ReScript 12 (and beyond).
Since this is relevant for the broader community, we wanted to give you an overview of what to expect for ReScript 12.
At this point we also want to thank our ReScript Retreat sponsor cca.io for providing us funding for the amazing event location! Also special thanks to @cknitt and @fham doing the big lift helping in organizing this event. A blog post about the event will follow soon.
1) Make rescript-core part of the compiler
Owner: @zth, @bloodyowl
rescript-core is considered stable enough to be part of the rescript compiler itself. It will replace all the competing standard library like modules, such as Js, Js2, Belt and the modules inherited from the OCaml stdlib (including, to some extent, Pervasives) to finally align on one streamlined API. Nice side-effect there is that the full API surface will be in ReScript syntax, so no ominous .ml files to jump to when looking up standard library functions.
Compatibility packages for the old stdlibs will be provided. Belt will continue to be maintained in a separate package.
We won’t go into details, but the main challenge here is switching compiler internal modules and tests to the new uncurried conventions.
2) Integrate rewatch as the new ReScript build system
Owner: @jfrolich @rolandpeelen and @cknitt
rewatch is an alternative build system for the ReScript compiler built in Rust. Contributors and power users had the chance to give rewatch a serious spin for their production codebases and it was deemed to be a superior solution over the original Ninja based build system that currently ships with ReScript (both in build times for incremental builds, as in feature wise e.g. with better monorepo support).
Our plan is to make rewatch the new ReScript build system that is responsible for calculating module dependency graphs and to efficiently compile modules. It will replace ninja and bsb and will help us build new capabilities such as faster/better monorepo support which was not as easy to do with the previous solution due to design constraints.
Once again, we are going the route of “vertical” integration by maintaining a tool that is custom tailored to our needs. This change is planned to not cause any serious breaking changes and users will continue to build their projects with rescript build and rescript build -w as always.
Depending on the usage patterns in the community, we may be thinking about removing the "in-source": false configuration within rescript.json (putting build artifacts into the lib/js folder), but this is still up for discussion and depends on how much of a breaking change this would be.
3) First class RegExp syntax
ReScript will finally get proper Regular expression syntax that will be similar / the same as in JS:
// Before
let r = %re("/b/g")
// After
let r = /b/g
A WIP branch was pushed during our retreat.
4) Better for/of and iterator support
Owner: @cometkim / @cristianoc and @JonoPrest.
ReScript will receive new capabilities to define and iterate through an iterator value, similar to JS.
Also, a builtin iterator type with corresponding bindings will be exposed for direct use.
In addition, there will be first experiments implementing a continue and break statement for loops to make the usage of loops more ergonomic. The first MVP will compile a break statement into a try/catch block, throwing an error at the break point.
5) Remove curried mode
Owner: @zth / @cristianoc
In ReScript 11, functions are uncurried by default. There’s still an option to opt into curried mode, which was originally introduced to not break any existing codebases and allow users to gradually migrate app and library code to ReScript 11’s uncurried semantics.
In ReScript 12, curried mode will be removed, which will be considered the biggest breaking change for this release. Removing curried functions will greatly reduce the complexity of the language, both on the user side and on the tooling side.
6) Remove .ml compilation support
Owner: @zth / @cristianoc
Given the fact that curried mode will be eliminated, .ml code will not be able to compile because OCaml only knows the concept of curried functions. Moving forward, ReScript 12 will drop support compiling any .ml files to JavaScript. As a consequence, all builtin ReScript modules will only be provided in .res syntax as well, further improving the user experience from an editor tooling perspective (go-to-source, type introspection, etc.).
Even though this is considered a breaking change, this will only impact a small fraction of our user base.
7) Improve reliability of the JSX parser for custom hyphenated prop names
Owner: @mununki
ReScript 12 will come with some internal parser improvements to fix issues such as Jsx parsing error where using hyphen prop name · Issue #6723 · rescript-lang/rescript-compiler · GitHub.
8) JSX: Use abstract types for React components (maybe)
Owner: @mununki
This is a lower level change in how React components are represented in the type space. The details why this change is needed can be found in this PR discussion.
This is considered a breaking change, although this will probably not impact many users.
9) JSX: Introduce preserve mode (maybe)
Owner: @mununki
This feature is mainly about preserving the original JSX in the compiled output, without applying any transformations. This feature should enable easier integration in non-React UI frameworks that rely on JSX.
10) Improve TS types output via genType
Owner: @cometkim / @cristianoc
The goal is to emit types that are more idiomatic to TypeScript users, including the generation of d.ts files.
11) Drop bs- prefixes in rescript.json
Owner: @cometkim
After our initial migrating from bsconfig.json to rescript.json, there were still some bs leftovers within the config file itself. In ReScript 12, this will be fixed by dropping all legacy bs- prefixes. For compatibility reasons, the deprecated names will still be supported.
12) First class embedded language support prototype
As a first step towards better meta programming support, we’ll start experimenting with a new builtin mechanic that tackles the “embedded language” problem, such as embedding graphql / css / edgedb queries etc. in your ReScript code.
The solution will be based on @zth’s rescript-embed-lang syntax extension.
13) Misc: Aligning Documentation, VSCode marketplace, Governance
Owner: @ryyppyy / @fham
- The
rescript-lang.orgrepository will be moved from the rescript-association to the rescript-lang org. This will also require us setting up a new public Vercel organization to hopefully allow easier collaboration and easy deployment of contributor branches. - The
rescript-association.orgwebsite will be migrated torescript-lang.orgfor better discoverability and more official character. We’ll also think about better solutions to allow easy donations (via stripe, GitHub sponsors, etc.) - The VSCode extension will be moved from the original
chenglou92organization to the actual official rescript-lang handle. This will include using the newly introduced VSCode extension deprecation mechanism to allow a seamless transition.
I hope this gives you a good idea on where we are heading, and we are looking forward for the big upcoming changes such as the new ReScript build system and the new builtin Core library that will ship with rescript@12.
As always we’ll make sure to keep the breaking change to a minimum and will give enough time to let you try release candidates and provide feedback to allow us to have a smooth transition phase.
Happy hacking!