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:
… 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. /=