stash/vendor/github.com/vektah/gqlparser/v2
WithoutPants 7a45943e8e
Stash box client interface (#751)
* Add gql client generation files
* Update dependencies
* Add stash-box client generation to the makefile
* Move scraped scene object matchers to models
* Add stash-box to scrape with dropdown
* Add scrape scene from fingerprint in UI
2020-09-17 19:57:18 +10:00
..
ast Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
formatter Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
gqlerror Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
lexer Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
parser Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
validator Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
.gitignore Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
go.mod Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
go.sum Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
gqlparser.go Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
LICENSE Stash box client interface (#751) 2020-09-17 19:57:18 +10:00
readme.md Stash box client interface (#751) 2020-09-17 19:57:18 +10:00

gqlparser CircleCI Go Report Card Coverage Status

This is a parser for graphql, written to mirror the graphql-js reference implementation as closely while remaining idiomatic and easy to use.

spec target: June 2018 (Schema definition language, block strings as descriptions, error paths & extension)

This parser is used by gqlgen, and it should be reasonablly stable.

Guiding principles:

  • maintainability: It should be easy to stay up to date with the spec
  • well tested: It shouldnt need a graphql server to validate itself. Changes to this repo should be self contained.
  • server agnostic: It should be usable by any of the graphql server implementations, and any graphql client tooling.
  • idiomatic & stable api: It should follow go best practices, especially around forwards compatibility.
  • fast: Where it doesnt impact on the above it should be fast. Avoid unnecessary allocs in hot paths.
  • close to reference: Where it doesnt impact on the above, it should stay close to the graphql/graphql-js reference implementation.