Discussions: some thoughts on make ppx devdepencies only

Development
1

Note this is not to encourage ppx usage, but to make some compromises to contain the negative impact of ppx.

Ppx mostly works on parsing, there are mostly three downsides of using ppx

  • It ties to the internal compiler APIs
  • It slows down compilation
  • It makes not only your library but also your dependent to depend on those native ppx plugins

But most PPXes stops after parsing.

I am thinking to have the build system in a mode to take the binary ast as input, mostly those *ast files in lib/bs. In this case for your dependent, they don’t need your ppx any more.

This proposal will address point 3, part of point 2, like every feature, it comes with a cost, would my proposal solve some real world problems, does it justify such complexity?

3 Likes
2

To rephrase if I understand correctly: the rescript compiler will only run the ppx on the application code and not the dependencies specified in bsconfig.json? I think that would be fine. (And dependencies can always specify the ppx they need internally explicitly).

3

After some thoughts, for security reasons, we can encourage users who use ppx distribute de-ppx-sugared source files

1 Like
4

Yes, agree. There is even an article in how Jane street is doing this: https://blog.janestreet.com/an-solution-to-the-ppx-versioning-problem/. This would definitely be a good solution if there would be a simple build command to achieve it.

5

Would the graphql and ReasonReact PPX continue to work with this proposal?