I just saw ppx_enum. really like it.
I use bucklescript in a vue js project. so, lots of cases I have to encode the string in js to bs type. a driving like this would be very help.
Does bs have a way to port the ppx_enum?
Thanks!
edit: with @ELLIOTTCABLE’s bs-deriving port. driving enum is possible, but it convert the variants to and from integers, which is not that useful as I expected.
I had basically the same disappointing experience with the [@@deriving enum] plugin — it’s clearly designed mostly for interop with C enums. ¯\_(ツ)_/¯
I posted in the OCaml-discourse thread about it, but I’d also really like to see ppx_enum integrated with ppx_deriving; it’d solve a lot of my own boilerplatey mess.
Anyway — providing native-OCaml ppx drivers on the npm-side isn’t really that difficult, it’s just a very annoying, mechanical process (setting up a bunch of CI tooling and versioning-automation to build native binaries for different platforms, and ship them off to npm; alongside any required runtime component as a second, separate npm package.
One additional wrinkle: the interesting part of what I published as bs-deriving is not the actual ppx_deriving component, but the included std collection of plugins. The major purpose of the real ppx_deriving is that it can resolve and dynlink to ‘plugins’ at runtime; AFAIK, this functionality is very specific to the native compilation system, OCaml compiler, and OCaml lookup paths. My npm package bypasses all of this, and statically compiles the set of std plugins into a single preproccesing-driver, which is then shipped to npm.
Thus, to support other deriving ‘plugins’, like ppx_enum, we’d not only have to package a second, separate pair of npm packages — every user would also have to run their code through both ppxes:
"bs-dependencies": [
...
"bs-deriving",
+ "bs-deriving-enum",
],
"ppx-flags": [
"ppx-deriving/ppx.js",
+ "ppx-deriving-enum/ppx.js",
],
… which quickly becomes prohibitive, and may have a noticible performance cost: all of the files are going to be read, parsed, and then later reserialized and written to disk, for each separate ppx-driver binary invoked. (I assume this is part of the reason ppx_deriving came to exist, so there’s only one binary driver for multiple stages of type-driven codegen — I’m pretty sure Dune also does something similar, compiling multiple API-compatible ppxes into a single driver-binary.)
tl;dr if you have a pressing need for ppx_enum, you can copy my approach and publish it as a separate package to npm. It’s not going to be too fun. For various reasons, the far better solution is to get that functionality mainlined into ppx_deriving itself; then for me to include it in the single prebuilt ppx-driver I’m already publishing. Unfortunately, that might take a while, slash isn’t guaranteed. /=