I don’t think anything has changed really in the stance towards PPXes - they’re still discouraged in general because of their complexity, maintenance burden etc. They also tend to be quite buggy, because working with the AST is difficult. We find bugs in our internal PPXes from time to time, so not even us who work on the compiler can get them right all of the time. It’s really easy to mess up tooling with them, and so on.
But as you note, there are still plenty of PPXes floating around and for some use cases a PPX is indeed the best solution and worth the trade off of being so complex. So, it’s about whether you’re willing to take the risk. It’s impossible to remove PPXes at this point without breaking most of the ecosystem (and community) so that’s not going to happen.
My personal view is: Be aware of the costs and the trade offs, and use PPXes only when the pros clearly offsets the cons. See how far you get without them, even if it means writing more code by hand. Make sure that when you do end up using a PPX, it adds to the DX in a way that’s just clearly much much better than the alternative.
One pretty concrete con to relying too much on PPXes is that as we evolve ReScript, we do a lot of “gymnastics” with the AST to represent new concepts without breaking the AST (and by that a bunch of tools). These gymnastics are likely to be painful to handle in PPXes. Pretty sure @alex.fedoseev is experiencing this as we speak with uncurried mode.
Regarding ppxlib etc, what has been stated before (and it’s still true) is that avoiding dependencies and preferably only depending on the (vendored, until we publish it to opam or similar) ReScript AST and compiler libs is what’ll give you the least amount of grief going forward. So, avoiding ppxlib is probably a good idea long term. I know @moondaddi at one point planned to ship a fork of ppxlib dedicated to ReScript.
It’s on our TODO to make working with the ReScript AST easier. Things like publishing all relevant compiler tools to opam, providing helpers an utils, and so on. But, it’s quite far down on the priority list. However, if someone feels knowledgeable in OCaml and would like to help out packaging up all of this and making it a better experience, then please do reach out. PPXes aside, we want people to be able to do innovative things with the AST and type system. Linters, code mods, etc. There’s plenty of stuff to explore, just that it doesn’t have a high priority relative to other things we’re working on.
Someone mentioned rescript-embed-lang: GitHub - zth/rescript-embed-lang: A general purpose PPX and library for embedding other languages into ReScript, via code generation.. It’s indeed a PPX, but it’s actually intended to reduce the overall need for PPXes. The idea is that you could embed other languages (SQL, GraphQL, EdgeQL, CSS, you name it) inside of ReScript, generate code and types from the sources you embed, and then have rescript-embed-lang just glue it together for you. Gluing it together here just means replacing the embedded code you’re writing with a link to the module you generate for that embedded code. It’s a pretty simple idea, but quite potent. And, it could be generalized to for example generate type assets for (flat) Remix routes in the future. Anyway, this is off topic. I’ll start a separate thread about rescript-embed-lang and the ideas around that eventually.
