resolvergen: use the resolver type as base name for dependent types

[fgallina]

The template was outputing invalid code since the resolver type was
not used in places like the embedding at {query,mutation}Resolver.

This change also ensures that objects like {query,mutation}Resolver
also use the user provided type name as suffix.

Here's the resulting diff on the code generation with type: GeneratedResolver in the resolver config:

diff -u resolver.go resolvernew.go
--- resolver.go 2019-05-26 20:04:15.361969755 -0300
+++ resolvernew.go      2019-05-26 20:04:54.170737786 -0300
@@ -7,20 +7,20 @@
 type GeneratedResolver struct{}

 func (r *GeneratedResolver) Mutation() MutationResolver {
-       return &mutationResolver{r}
+       return &mutationGeneratedResolver{r}
 }
 func (r *GeneratedResolver) Query() QueryResolver {
-       return &queryResolver{r}
+       return &queryGeneratedResolver{r}
 }

-type mutationResolver struct{ *Resolver }
+type mutationGeneratedResolver struct{ *GeneratedResolver }

-func (r *mutationResolver) CreateTodo(ctx context.Context, input NewTodo) (*Todo, error) {
+func (r *mutationGeneratedResolver) CreateTodo(ctx context.Context, input NewTodo) (*Todo, error) {
        panic("not implemented")
 }

-type queryResolver struct{ *Resolver }
+type queryGeneratedResolver struct{ *GeneratedResolver }

-func (r *queryResolver) Todos(ctx context.Context) ([]*Todo, error) {
+func (r *queryGeneratedResolver) Todos(ctx context.Context) ([]*Todo, error) {
        panic("not implemented")
 }

I haven't yet found the place where this is tested nor the sensible way to add test for this use case. Will update as soon as I find it.

I have:

• Added tests covering the bug / feature (see testing)
• Updated any relevant documentation (see docs)

[mathewbyrne]

Can you please add a test case demonstrating the issue? It looks like none of the generated code has changed from to your update.

[fgallina]

@mathewbyrne I think that may be related to the fact that the resolver.go generation is skipped if the file already exists. Also there must be a custom resolver type in the gqlgen.yml to exercise these changes. Excerpt from my original config that drove me to propose this change:

...
resolver:
  filename: graphql/resolver.go
  package: graphql
  type: GeneratedResolver

[seriousben]

Maybe an easier and simpler way to write this test would be to use golden files (https://medium.com/@jarifibrahim/golden-files-why-you-should-use-them-47087ec994bf)

[vektah]

We already do this using code review of the committed generated files. No need for update, just commit the generated code and push.

All this test should need to do is call the generator with some config, eg. It may not look like its asserting anything, but really its output is tested in three ways:

• firstly we run goimports when saving go files, so running generate should error out in the test if it generates invalid code.
• if that fails the linter should see invalid code, and fail the branch.
• code review catches changes. diffs are readable in github.

[vektah]

😆

[vektah]

We already do this using code review of the committed generated files. No need for update, just commit the generated code and push.

All this test should need to do is call the generator with some config, eg. It may not look like its asserting anything, but really its output is tested in three ways:

• firstly we run goimports when saving go files, so running generate should error out in the test if it generates invalid code.
• if that fails the linter should see invalid code, and fail the branch.
• code review catches changes. diffs are readable in github.