0.4.1

Fixed

• Introspection api was not returning args or default values

0.4.0

Updating to 0.4.0 is going to require a few things:

• Update any references to github.com/vektah/gqlgen to point to github.com/99designs/gqlgen
• Delete any existing generated code to remove broken imports paths
• Run dep ensure -update github.com/99designs/gqlgen github.com/vektah/gqlparser
• Update your handler from graph.NewExecutableSchema(&graph.Graph...) to graph.NewExecutableSchema(graph.Config{Resolvers: &graph.Graph...})
• go generate ./...

Removed

• The old (underscore separated) resolver syntax is no longer supported

Changed

• Moved repo from github.com/vektah/gqlgen to github.com/99designs/gqlgen
• Switched the parser over to gqlparser, which brings us up to date with the June 2018 spec. This includes better directive support and a bunch of bug fixes around validation.
• The implicit prelude no longer includes custom types defined by gqlgen. This means if you are using Map or Time you will need to add scalar Map to your schema. The default implementations are still provided, but the type isn't being included automatically in the schema.
• A bunch of internal interfaces have changed slightly. They should all break in fairly obvious ways.
• To support directives NewExecutableSchema now takes a config object.
• Generated models are now more linter friendly, following the same capitalization rules in go lint for common acronyms.
• ResolverMiddleware has been renamed to FieldMiddleware, and now runs on every field.
• Descriptions in introspection now need to use block syntax instead of comments, """this is a field description"""
• Custom unmarshallers need to handle json.Number to prevent loss of precision when using variables

Added

• gqlgen init: You can now create a project skeleton quickly and easily
• gqlgen will now generate resolver stubs if you specify the new resolver config key.
• Support for field directives in schema: This is the most common use case, more will follow. see #228 for planning for other directive types.
• Support for @skip and @include
• Added ability to map to different field names when binding to existing models

Fixed

• Scalars passed into array contexts will now correctly be coerced into arrays
• Variables will now have their types validated properly.
• Large ints in variables were losing precision after 52 bits due to a float bug.

0.3.0

Changed

• Method return values must now match expected type, if not a resolver is added - #193
• Nullability is now applied correctly in lists - #191
• Multiple error from the same resolver are now supported - #186

Added

• Resolvers can be forced for generated types - #190

Fixed

• Multiline comments on enums no longer break output - #194
• Config will now complain about unknown keys - #192

0.2.5

Fixed

• Windows is now supported, and we have CI to match - #188

0.2.4

Fixed

• Config keys now have more validation and give good error messages - #179
• Code generation now takes the package name from any existing files in the directory - #179
• A bug when auto casting between types in external packages - #180

0.2.3

Added

• support for forcing resolver generation, even when there is a matching field to bind to - #173
• search for config in more places - #176
• docs for config config - https://gqlgen.com/config/

0.2.2

Deprecated

• typemap.json has been deprecated in favour of .gqlgen.yml - #163

Fixed

• Bug when using multiple gopaths - #151
• Generate enums even if there are no models - #159
• Circular references causing generation not to run - #166

0.2.1

Added

• Support for smaller resolver interfaces that don't use _ as a separator, see #106 and #134

Fixed

• generated file header format, gofmt will now ignore these files #139
• missing , when unpacking defaults in input objects #146
• when importing a package use the real package name #147

0.2.0

Added

• Going forward we will start tracking change logs 🎉

Changes

Previously

type User {
    id Int!
    notes [Notes!]!
}

would generate only generate the ID, not the notes:

type User struct {
    id int
}

It now will generate exactly what is in the schema:

type User {
    id int
    notes []Notes
}

This feature was generating a lot of confusion with some expecting the notes field to be present. If you were relying on this behavior you should copy the old model out of the generated code and add it to your types.json.

A future release will add better support for explicitly configuring this behaviour. Proposed syntax is:

type User {
    id Int!
    notes [Notes!]! @resolver
}