Think about which traits have to be derived for the response structs and enums

[tomhoule]

Should we derive a lot of traits and rely on dead code elimination?

Should we allow users of the library to specify which ones they want to derive? (with just Deserialize as a default)

[LegNeato]

FWIW as a user I would expect any derives placed on the origin struct to be propagated to the resulting generated code. That being said, Debug and PartialEq are pretty useful and might be decent defaults.

[tomhoule]

That seems like an intuitive way to do it. I don't know if derive macros have access to the derive attribute - my guess would be yes.

Since wasm in browsers is a possible use-case for this library and code size matters there, it's important to give users of the library control over that imo. I have read that Debug and string formatting in general tends to bloat binaries, so it might even make sense to make that non-default (it would be nice to find a source for that claim, I'll look for it).

[tomhoule]

I started work on this, and custom derive macros don't have access to the #[derive()] attributes, (see https://docs.rs/syn/0.14.7/syn/struct.DeriveInput.html - it's not in attrs). I think I am going to implement it as options inside the #[graphql] attribute for now.

[tomhoule]

Done in #79