Hey, I try to figure it out what is the current PPX support state in rescript, and what is the futur.
If I understand correctly, rescript doesn’t (and will not ?) support the “new” ppxlib, so we’re stuck on old PPX version or if the lib maintainer is willing to keep a compatible version, is that correct ? Does melange support ppxlib ?
Also, the use of ppx does not seem to be encouraged, am I right?
I can see in the roadmap: PPX only allowed on top level packages?, what does that mean ?
I’m new to rescript (and ocaml for what is worth), I’m a bit confused about it…
If you are new to ReScript and plan to write some production code (instead of just playing it), you are not encouraged to investing your time in PPX or PPX based technologies.
Ok got it, rescript is actually a new language I try to introduce in my company. I don’t plan to build ppx for that anyway (but probably play with it for myself), I just want to understand the actual state and the future about it, for the sake of understanding what food I eat and give to my colleagues.
However, I think some documentation (or at least a post in this forum) to clarify should be great. I understand you want to discourage the use of PPX, but it’s currently a part of rescript that matters (e.g: decco seems to be widely used at the time I write this post).
I’ve spent a lot of time trying to figure out what’s going on with PPX and I’m not sure I understand it correctly, I think it can benefit any newcomer.
Sure, got it. Is it because it’s complicate and considered as a “bad practice” or it’s because support will be drop or potentially drop ?
I don’t want to sound rough, but that’s just what I did and you only tell me “don’t do that”, even after I explain that it’s for the sake of understanding and curiosity.
Maybe my questions doesn’t sound like questions and I apologize for that, so I reformulate:
Did I understand correctly the ppxlib thing ?
What does PPX only allowed on top level packages? (on the roadmap) mean ?
TLDR: PPX is very complicated, we don’t want to break your code, but we probably will break your code unintentionally and if that’s the case, we will not revert the changes.
Ppxlib is even worse, it has no place in the roadmap of rescript. We will provide our own compiler APIs instead, but our own compiler API is still discouraged and it is only okay for complex stuff instead of trivial things.
Please take mine too with good intention too, I know there is nothing easy with managing a community around a language, especially rescript.
Another question maybe off topic: As I talked there: Record/Module generate through JSON but aware of it during build time? - #4 by kk3 , we are looking for (in the future, it’s just anticipation and probably overthinking, but I think it’s an interesting topic) to include a json typed as a record during build time, in a similar fashion that we can do require('my.json') in javascript, so we can take advantage of the rescript compiler optimization (e.g: avoid switch if only one case is possible, given that the record is declare and will not change).
I first though of an hacky way without PPX by writing a res file from this json, but in this case, as long as rescript doesn’t support it natively, it feels like the proper way for this is to use PPX. If we should avoid them, what is the proper way to achieve something similar ?
I first though of an hacky way without PPX by writing a res file from this json, but in this case, as long as rescript doesn’t support it natively, it feels like the proper way for this is to use PPX
Code generator sounds hacky but it is much more reliable, since it only relies on the concrete syntax which rarely changes. PPX would rely on a large set of undocumented API and marshall compatibility, hence I would recommend the first approach for your use case
Maintainer of rescript-relay here - from what I understand from @Hongbo , everything rescript-relay uses in terms of PPX will continue to work (although the PPX code itself will likely need to be migrated and possibly changed some). So, in short, yes.
rescript-relay powers a growing amount of production ReScript apps, and both me and my consultancy is committed to supporting it for a long long time, so unless a hard roadblock appears (like PPX support being removed entirely), it’ll continue to work and be supported.
The bulk of the code generated, like all of the types derived from the GraphQL definitions, is actually from codegen (via the Relay compiler) right now. What the PPX primarily is used for is tying together the generated files with the local module defining them, as well as conditionally exposing functions only if certain criteria are met.
While the “if all else fails” plan is of course that we could transition to only codegen, I still consider the things the PPX does right now crucial to the DX. And having as good/ergonomic DX as we can is one of the main goals.
I agree to @zth. I’ve been looking for a long time for a seamless codegen DX in TypeScript. Mainly for gatsby-plugin-typegen or new frontend compilers.
Developers don’t like to have multiple build pipelines surfaced, and the more steps, the more complicated. (my only successful ReScript PT was when I showed ReScript Relay to fellow developers using Relay)
Macros like PPX is killer, codegen will never catch up to it. Or some third-party tools/frameworks tying people in a worse way than language extension do.
- from what I understand from