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.
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 changes the parsing grammar and validation rules to more correctly implement the current state of the GraphQL SDL proposal (facebook/graphql#90)
ref: graphql/graphl-js#1102
* Generalizes building a value from an AST, since "scalar" could be misleading, and supporting variable values within custom scalar literals can be valuable.
* Replaces isNullish with isInvalid since `null` is a meaningful value as a result of literal parsing.
* Provide reasonable default version of 'parseLiteral'
ref: 714ee980aa
ref: https://github.com/graphql/graphql-js/pull/903
# Conflicts:
# src/Utils/BuildSchema.php
# tests/Utils/BuildSchemaTest.php
As discussed in facebook/graphql#90
This proposes replacing leading comment blocks as descriptions in the schema definition language with leading strings (typically block strings).
While I think there is some reduced ergonomics of using a string literal instead of a comment to write descriptions (unless perhaps you are accustomed to Python or Clojure), there are some compelling advantages:
* Descriptions are first-class in the AST of the schema definition language.
* Comments can remain "ignored" characters.
* No ambiguity between commented out regions and descriptions.
Specific to this reference implementation, since this is a breaking change and comment descriptions in the experimental SDL have fairly wide usage, I've left the comment description implementation intact and allow it to be enabled via an option. This should help with allowing upgrading with minimal impact on existing codebases and aid in automated transforms.
BREAKING CHANGE: This does not parse descriptions from comments by default anymore and the value of description in Nodes changed from string to StringValueNode
This RFC adds a new form of `StringValue`, the multi-line string, similar to that found in Python and Scala.
A multi-line string starts and ends with a triple-quote:
```
"""This is a triple-quoted string
and it can contain multiple lines"""
```
Multi-line strings are useful for typing literal bodies of text where new lines should be interpretted literally. In fact, the only escape sequence used is `\"""` and `\` is otherwise allowed unescaped. This is beneficial when writing documentation within strings which may reference the back-slash often:
```
"""
In a multi-line string \n and C:\\ are unescaped.
"""
```
The primary value of multi-line strings are to write long-form input directly in query text, in tools like GraphiQL, and as a prerequisite to another pending RFC to allow docstring style documentation in the Schema Definition Language.
Ref: graphql/graphql-js#926
