aeson 2 introduces its own Object type (
KeyMap) and an update would probably break compatibility. Since this GraphQL implementation defines its own types for its internal representation and uses aeson only during the value completion, it shouldn't depend on any specific serialization format. GraphQL specification doesn't require JSON support either. Adding various serialization formats is possible by writing a few typeclass instances. So it is a good chance to create another package, GraphQL "battery included", and provide aeson 2 support there. This is also a good showcase to prove that other serialzation formats can be implemented, be it JSON, XML or something else. This will be a long process.
- Create a package with Aeson 2 instances. The package can get other extras over time. Convenience functions in
Language.GraphQLcan be moved too.
- Document Aeson-dependent functions and instances as deprecated.
- After some time deprecate the APIs above in some major release.
- Remove the APIs in another major release.