Native: Libraries in the PPX can sometimes conflict with user-code

[lessp]

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

[jfrolich]

Yeah I think shipping a runtime module is the best option to keep compatibility with < 4.08

[jfrolich]

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.