graphql-ppx
graphql-ppx copied to clipboard
Native: Libraries in the PPX can sometimes conflict with user-code
e.g. if you open another library which also has a module which the ppx uses but doesn't implement the same functions you'll hit unbound value
. In my case I used another standard library which did not implement List.assoc
.
open AnotherStdlib;
[%graphql {| ... |}]
Some solutions were discussed in an earlier PR https://github.com/reasonml-community/graphql-ppx/pull/178#issuecomment-662721984:
A couple alternatives:
adding stdlib-shims to this project (less desirable to me)
fix this is tablecloth: Base and Core have Caml modules that allow you to recover OCaml stdlib functionality by opening that module. In your case you'd be able to do:
open Caml
(* from this point on, List
refers to Stdlib.List *)
module YourQuery = [%graphql ...]```
From the OCaml Discord:
IIRC, ppx_deriving tries to hack around this issue by including everything it needs in a Ppx_deriving_runtime module. So if it needs Stdlib.List.iter it will alias Stdlib.List as Ppx_deriving_runtime.List and call Ppx_deriving_runtime.List.iter in its generated AST An update to graphql_ppx to do the same by aliasing its modules under a Graphql_ppx_runtime module might help. Unfortunately there isn't a good/easy fix from a user's perspective This may be a better approach for the future if people would keep hitting these, what do you think? I guess we'd still include the shims if support for 4.0.6 is desirable!
https://github.com/ocaml-ppx/ppx_deriving/blob/master/src/runtime/ppx_deriving_runtime.cppo.ml
Yeah I think shipping a runtime module is the best option to keep compatibility with < 4.08
We can backfit this on the native ppx now. But the plan is to make the Bucklescript ppx universal so it should definitely be part of that PR.