mirror of
https://github.com/stashapp/stash.git
synced 2025-12-18 12:54:38 +03:00
45f700d6ea
* Upgrade gqlgen to v0.17.2 This enables builds on Go 1.18. github.com/vektah/gqlparser is upgraded to the newest version too. Getting this to work is a bit of a hazzle. I had to first remove vendoring from the repository, perform the upgrade and then re-introduce the vendor directory. I think gqlgens analysis went wrong for some reason on the upgrade. It would seem a clean-room installation fixed it. * Bump project to 1.18 * Update all packages, address gqlgenc breaking changes * Let `go mod tidy` handle the go.mod file * Upgrade linter to 1.45.2 * Introduce v1.45.2 of the linter The linter now correctly warns on `strings.Title` because it isn't unicode-aware. Fix this by using the suggested fix from x/text/cases to produce unicode-aware strings. The mapping isn't entirely 1-1 as this new approach has a larger iface: it spans all of unicode rather than just ASCII. It coincides for ASCII however, so things should be largely the same. * Ready ourselves for errchkjson and contextcheck. * Revert dockerfile golang version changes for now Co-authored-by: Kermie <kermie@isinthe.house> Co-authored-by: WithoutPants <53250216+WithoutPants@users.noreply.github.com>
1.5 KiB
1.5 KiB
gqlparser 
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 reasonably stable.
Guiding principles:
- maintainability: It should be easy to stay up to date with the spec
- well tested: It shouldn't 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 doesn't impact on the above it should be fast. Avoid unnecessary allocs in hot paths.
- close to reference: Where it doesn't impact on the above, it should stay close to the graphql/graphql-js reference implementation.