-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support .gqlgen.yml #163
support .gqlgen.yml #163
Conversation
- typeName: User
entityPath: remote_api.User
fields:
- fieldName: likes
resolver: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the PR but I think this needs a bit more thought.
I was picturing something more like
models:
User:
model: github.com/my/pkg/user.User
fields:
ID:
resolver: true
Because the unique element (typeName, fieldName) are keys, linters will fail on dupes.
Also if we head down this path I think we should just deprecate (and provide command to convert) the old format to the new.
It probably probably becomes a more general .gqlgen.yml and should probably support setting all the command line args.
main.go
Outdated
} | ||
|
||
if strings.HasSuffix(*typemap, ".json") { | ||
return loadTypeMapJSON() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yaml is a superset of json, so you should be able to remove the json codepath here entirely.
This also means you can use yaml comments in json files and leave on trailing newlines I think.
@vektah thank for advice! I added support about
and, user use
|
support .gqlgen.yml
refs #161
I'm implemented types.yaml support 👍
Now, We can processing 3 forms of
types.*
file.old one.
JSON form.
YAML form.
If json is used it may be better to display an error to use yaml.