Ben Kraft
67f2575cae
In #133, Craig added support for a new use of typename, where it applies to a scalar and means that genqlient should generate a named type, e.g. `# @genqlient(typename: "MyString")` on a node of type string will generate and use `type MyString string`. But this gets a bit confusing if you mix it with `bind`; should `typename: "MyString", bind: "int32"` generate `type MyString int32`, or should one override the other, or what? Of course in practice you're not likely to write that all in one place, but you could via a global binding, or a `for` directive, and in that case probably it was a mistake. In #138, we looked at making them work together correctly, but it added complexity and got even more confusing. So instead, here, we just ban it; we can always add it back if it proves useful. (Or, you can make the `typename` win over a global binding by locally unbinding it via `bind: "-"`.) This required changes in surprisingly many places; I already knew the directive-validation code was due for a refactor but that will happen some other day. The tests show that it works, in any case. Interestingly, this problem actually could have arisen for a struct binding already, before #133. But all the same reasons it's confusing seem to apply, so I just banned it there too. This is technically a breaking change although I doubt anyone will hit it. Test plan: make check
5.2 KiB
5.2 KiB
Changelog
next
Breaking changes:
- The
ConfigfieldsSchemaandOperationsare now both of typeStringList. This does not affect configuration viagenqlient.yaml, only via the Go API. - The
typenameandbindoptions may no longer be combined; doing so will now result in an error. In practice, any such use was likely in error (and the rules for which would win were confusing and undocumented).
New features:
- genqlient now generates getter methods for all fields, even those which do not implement a genqlient-generated interface; this can be useful for callers who wish to define their own interface and have several unrelated genqlient types which have the same fields implement it.
- genqlient config now accepts either a single or multiple files for the
schemaandoperationsfields (previously it accepted only oneschema, and required a list ofoperationsfiles). - The
typenameoption can now be used on basic types (string, int, etc) as well as structs; this can be useful to have genqlient define new types liketype Language stringand use that type for specified fields.
Bug fixes:
- In certain very rare cases involving duplicate fields in fragment spreads, genqlient would generate code that failed to compile due to duplicate methods not getting promoted; genqlient now generates correct types. (See #126 for a more complete description.)
v0.3.0
Version 0.3.0 adds several new configuration options, allowing simplification of generated types and configuration of input types, as well as marshalers for all genqlient-generated types.
Breaking changes:
- Previously,
# @genqlientdirectives applied to entire operations applied inconsistently to fields of input types used by those operations. Specifically,pointer: true, when applied to the operation, would affect all input-field arguments, butomitempty: truewould not. Now, all options apply to fields of input types; this is a behavior change in the case ofomitempty.
New features:
- genqlient's types are now safe to JSON-marshal, which can be useful for putting them in a cache, for example. See the docs for details.
- The new
flattenoption in the# @genqlientdirective allows for a simpler form of type-sharing using fragment spreads. See the docs for details. - The new
foroption in the# @genqlientdirective allows applying options to a particular field anywhere it appears in the query. This is especially useful for fields of input types, for which there is otherwise no way to specify options; see the documentation on handling nullable fields for an example, and the# @genqlientdirective reference for the full details.
Bug fixes:
v0.2.0
Version 0.2.0 adds several convenience features for using custom scalars, as well as many internal improvements and bug fixes.
Breaking changes:
- The
graphql.Clientinterface now acceptsvariables interface{}(containing a JSON-marshalable value) rather thanvariables map[string]interface{}. Clients implementing the interface themselves will need to change the signature; clients who simply callgraphql.NewClientare unaffected. - genqlient's handling of the
omitemptyoption has changed to match that ofencoding/json, from which it had inadvertently differed. In particular, this means struct-typed arguments with# @genqlient(omitempty: true)will no longer be omitted if they are the zero value. (Struct-pointers are still omitted if nil, so addingpointer: truewill typically work fine. It's also now possible to use a custom marshaler to explicitly map zero to null.)
New features:
- The new
bindings.marshalerandbindings.unmarshaleroptions ingenqlient.yamlallow binding to a type without using its standard JSON serialization; see the documentation for details. - Multiple genqlient directives may now be applied to the same node, as long as they don't conflict; see the directive documentation for details.
Bug fixes:
- The
omitemptyoption now works correctly for struct- and map-typed variables, matchingencoding/json, which is to say it never omits structs, and omits empty maps. (#43) - Generated type-names now abbreviate across multiple components; for example if the path to a type is
(MyOperation, Outer, Outer, Inner, OuterInner), it will again be calledMyOperationOuterInner. (This regressed in a pre-v0.1.0 refactor.) (#109) - Previously, interface fields with
# @genqlient(pointer: true)would be unmarshaled to(*MyInterface)(*<nil>), i.e. a pointer to the untyped-nil of the interface type. Now they are unmarshaled as(*MyInterface)(<nil>), i.e. a nil pointer of the pointer-to-interface type, as you would expect.
v0.1.0
First open-sourced version.