For misspelled enums or field names, these suggestions can be helpful.
This also changes the suggestions algorithm to better detect case-sensitivity mistakes, which are common
ref: graphql/graphql-js#1153
This generalizes the "arguments of correct type" and "default values of correct type" to a single rule "values of correct type" which has been re-written to rely on a traversal rather than the utility function `isValidLiteralValue`. To reduce breaking scope, this does not remove that utility even though it's no longer used directly within the library. Since the default values rule included another validation rule that rule was renamed to a more apt "variable default value allowed".
This also includes the original errors from custom scalars in the validation error output, solving the remainder of graphql/graphql-js#821.
ref: graphql/graphql-js#1144
This includes:
graphql/graphql-js#1147graphql/graphql-js#355
This also fixes two bugs in the Schema
- types that were not found where still added to the typeMap
- InputObject args should not be searched for types.
There are possibilities for errors during validation if a schema is not valid when provided to TypeInfo. Most checks for validity existed, but some did not. This asks flow to make those checks required and adds the remaining ones. Important now that we allow construction of invalid schema.
ref: graphql/graphql-js#1143
This is a fairly major refactoring of coerceValue which returns an Either so it can return a complete collection of errors. This allows originalError to be preserved for scalar coercion errors and ensures *all* errors are represented in the response.
This had a minor change to the logic in execute / subscribe to allow for buildExecutionContext to abrupt complete with multiple errors.
ref: graphql/graphql-js#1133
If a GraphQLError represents multiple nodes across files (could happen for validation across multiple parsed files) then the reported locations and printError output can be incorrect for the second node. This ensures locations are derived from nodes whenever possible to get correct location and amends comment documentation.
ref: graphql/graphql-js#1131
This moves validation out of GraphQLSchema's constructor (but not yet from other type constructors), which is responsible for root type validation and interface implementation checking.
Reduces time to construct GraphQLSchema significantly, shifting the time to validation.
This also allows for much looser rules within the schema builders, which implicitly validate while trying to adhere to flow types. Instead we use any casts to loosen the rules to defer that to validation where errors can be richer.
This also loosens the rule that a schema can only be constructed if it has a query type, moving that to validation as well. That makes flow typing slightly less nice, but allows for incremental schema building which is valuable
ref: graphql/graphql-js#1124
Lifted from / inspired by a similar change in graphql/graphql-js#722, this creates a new function `printError()` (and uses it as the implementation for `GraphQLError#toString()`) which prints location information in the context of an error.
This is moved from the syntax error where it used to be hard-coded, so it may now be used to format validation errors, value coercion errors, or any other error which may be associated with a location.
ref: graphql/graphql-js
BREAKING CHANGE: The SyntaxError message does not contain the codeframe anymore and only the message, (string) $error will print the codeframe.
This factors out the enum value validation from scalar value validation and ensures the same try/catch is used in isValidLiteralValue as isValidPHPValue and protecting from errors in valueFromAST.
ref: graphql/graphql-js#1126
A common case is encountering an error which blames to a single AST node. Ensure the GraphQLError constructor can handle this case.
ref: graphql/graphql-js#1123
