Comments (1)
You are entirely correct that this is a behavior change, and I regret the extra work this may have caused you and others. This library has not easily exposed configuration settings to allow people to opt-in to behavioral changes.
As a result, I am not able to guarantee preserving the backward compatibility of gqlparser
for past, existing, or future bugs. Additionally, maintaining compatibility to an evolving GraphQL spec may also sometimes require breaking backward compatibility. The Go language itself has this backward compatibility guarantee:
Although we expect that the vast majority of programs will maintain this compatibility over time, it is impossible to guarantee that no future change will break any program. This document is an attempt to set expectations for the compatibility of Go 1 software in the future. There are a number of ways in which a program that compiles and runs today may fail to do so after a future point release. They are all unlikely but worth recording.
- Security. A security issue in the specification or implementation may come to light whose resolution requires breaking compatibility. We reserve the right to address such security issues.
- Unspecified behavior. The Go specification tries to be explicit about most properties of the language, but there are some aspects that are undefined. Programs that depend on such unspecified behavior may break in future releases.
- Specification errors. If it becomes necessary to address an inconsistency or incompleteness in the specification, resolving the issue could affect the meaning or legality of existing programs. We reserve the right to address such issues, including updating the implementations. Except for security issues, no incompatible changes to the specification would be made.
- Bugs. If a compiler or library has a bug that violates the specification, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.
- Struct literals. For the addition of features in later point releases, it may be necessary to add fields to exported structs in the API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to create values of these types would fail to compile after such a change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"}) will continue to compile after such a change. We will update such data structures in a way that allows keyed struct literals to remain compatible, although unkeyed literals may fail to compile. (There are also more intricate cases involving nested data structures or interfaces, but they have the same resolution.) We therefore recommend that composite literals whose type is defined in a separate package should use the keyed notation.
- Methods. As with struct fields, it may be necessary to add methods to types. Under some circumstances, such as when the type is embedded in a struct along with another type, the addition of the new method may break the struct by creating a conflict with an existing method of the other embedded type. We cannot protect against this rare case and do not guarantee compatibility should it arise.
- Dot imports. If a program imports a standard package using import . "path", additional names defined in the imported package in future releases may conflict with other names defined in the program. We do not recommend the use of import . outside of tests, and using it may cause a program to fail to compile in future releases.
The GraphQL documentation gives these examples showing omitting parenthesis for queries when there are no arguments:
type Query {
books: [Book]
authors: [Author]
}
And the spec states that if you try to add empty parenthesis like:
query GetSomething() { # <-- empty arguments list here
user() { # <-- empty argument list here
name
}
}
There should be a validation error in Line 1 and Line 2 each because in GraphQL, Arguments must contain at least one Argument. In GraphQL spec, the notation [list] means one or more -- see spec definition
Note that the entire "Arguments" portion is optional in both contexts, therefore query GetSomething { ... } is allowed and so is user { ... }, but if the braces () are present they must contain something.
The graphql-js reference implementation reports errors on both cases correctly.
This parser used to allow empty parenthesis, but we are trying to maintain spec compliance. The change was made here:
#293
I again regret the additional work this forced upon you and others, but I hope you can understand my reasoning and motivation.
from gqlparser.
Related Issues (20)
- Github Actions for code linting / testing of PRs? HOT 2
- proposal: Add benchmark
- Unexpected Name "directive"
- Add `Is(err error) bool` to gqlerror to work with `errors.Is` HOT 2
- Can I use this library to generate a graphql response payload?
- Can I parse the type of a field from query and schema?
- Columns are negative for fields with multi-line comments HOT 1
- Can I get the value of a directive on the schema?
- FormatSchemaDocument and FormatQueryDocument support to print comments HOT 2
- Could you please publish a new tag? HOT 2
- Error parsing @join__type directive on supergraph HOT 6
- `errors.As` usage is broken as of v2.5.9
- Bug in gqlerror.List.As()
- Question: can I set a limit to the maximum number of tokens allowed in a request? HOT 1
- [Trivial] Formatter - Descriptions with a double quotes fail to produce correct graphql code.
- Empty argument lists () should be disallowed HOT 2
- call with empty parameter list is considered a parse error HOT 2
- possible denial of service attack due to unlimited errors HOT 7
- New maxTokenLimit default causing breaking change in large schemas HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gqlparser.