The future of Rescript compiler plugin support

Announcements
#1

Dear ReScript users:

The compiler plugin (or called ppx) is a complexity beast, it is worse in a native language that does not offer stable ABI or not have something like NAPI. It is generally not recommended to write compiler plugins for trivial tasks or saving some bolierplate code, code generator may serve you better.

We are aware of that some compiler plugins are used in some commercial applications so that we are not going to make any changes in the next major version (V10).

Moving forward, we are going to provide our own compiler libs, so if you do want to write compiler plugins (I hope you do not), you need develop your AST transformations based on our provided compiler libs. To make that transition easier, you are encouraged to have your current compiler plugin have less dependencies. For example, if your current ast transformations only depends the type definitions without any third party dependencies, it should be easy to adapt it for rescript compiler libs.

For some commonly used derivings, for example, comparison deriving, we will investigate that if we could provide built-in support.

11 Likes
#2

Thanks Hongbo for the clear statement!
For me the crucial one is of course graphql. Can you make some explicit plan for rescript and graphql?

Thanks
Alex

8 Likes
#3

I’ve been using decco for a long time now, and a compiler plugin still seems like the best way to handle JSON types, but as my project grew the overhead of running a ppx on every file became too much. I’m working on some changes to improve the use of atdgen with ReScript and hope to migrate my project to that to it the next week or so. Initial indications are it speeds up overall build time by 20-25%.

4 Likes
#4

I’m curious about the timeline for this. Not in v10, but likely in v11 I guess?

Is there a plan yet for when the compiler libs could be made available so we can start testing and assessing the amount of work needed to migrate to them? Also, any more details on what you intend on providing in terms of the libs?

I’m guessing compiler plugins will still be in OCaml, right? Any info on what OCaml version will be targeted?

Thanks!

3 Likes
#5

The V10 will have a one year life cycle starting from 2022

I’m guessing compiler plugins will still be in OCaml, right? Any info on what OCaml version will be targeted?

Yes, we will figure out the details next year.

The intention of this post is that most existing compiler plugins for Rescript depend on ocaml-compiler-libs which happens to work with ReScript, this makes us hard to change the compiler API.

We will provide similar API, so that new PPXes will be targeted to rescript-compiler-libs so we have flexibilities to change it.

To make your transition easier, if you only depend on parsetree type definitions instead of ocaml-migrate-parsetree or ppxlib, it should be easy.

#6

Can you make some explicit plan for rescript and graphql?

That will depend on graphql ppx authors.

#7

It sounds like we need to make sure ppx just have to directly work with the parse tree and not use things like ppxlib (and depend on a potentially diverging ReScript parse tree). I think this makes sense and wouldn’t be a big problem. My only concern is if we have access to metaquote and Ast_helper, but I think that shouldn’t be a problem, and if it is we can vendor it in?

Moving graphql-ppx to directly use the 4.06 parse tree for ReScript is something that is in the plans for some time (and once ReScript is creating it’s own compiler libs that will probably be an easy adjustment). I just didn’t start with it yet.

7 Likes
#8

Thanks for bringing that up, I’m also interested in metaquot and Ast_helper. Maybe it’s a bit early though for those types of details, or what do you say @Hongbo ?