[pull] 16.x.x from graphql:16.x.x #203
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Motivated by #3178
Depends on #3115 Implements RFC at graphql/graphql-spec#849. * Replaces `isSourceCharacter` with `isUnicodeScalarValue` * Adds `isSupplementaryCodePoint`, used in String, BlockStrings, and Comments to ensure correct lexing of JavaScript's UTF-16 source. * Updates `printCodePointAt` to correctly print supplementary code points. * Adds variable-width Unicode escape sequences * Adds explicit support for legacy JSON-style fixed-width Unicode escape sequence surrogate pairs. * Adds `printString` to no longer rely on `JSON.stringify`. Borrows some implementation details from Node.js internals for string printing. Implements: > When producing a {StringValue}, implementations should use escape sequences to > represent non-printable control characters (U+0000 to U+001F and U+007F to > U+009F). Other escape sequences are not necessary, however an implementation may > use escape sequences to represent any other range of code points. Closes #2449 Co-authored-by: Andreas Marek <[email protected]>
Co-authored-by: Ivan Goncharov <[email protected]>
#3261) We maintained this hack for a long time to make our Errors compatible with with chai's `to.deep.equal`
With previous timeout Webpack test was failing on CI from time to time
* lexer: Remove superfluous statement in `readDigits` * review changes Co-authored-by: Ivan Goncharov <[email protected]>
Co-authored-by: Ivan Goncharov <[email protected]>
Ultimately I was trying this out to see whether we can tweak the docs easily, it made me realize that our docs are tailored to general GraphQL rather than how do we use this library. It made me come up with a few suggestions - We should have a toggle on code examples to switch between `buildSchema` and programatically creating the schema with i.e. `GraphQLObjectType` - Our documentation starts with a tutorial, this ultimately feels like a mistake, we should lead with an explanation of what GraphQL.JS is and what it aims to do, clearly outlining the goals of this project - We should line out use-cases for building on this library and best practices of how to go to production Resolves #2941 Resolves #2567
Not quite sure yet about contents of the overview page, also the header is pretty odd, feels like a nextra bug or I goofed the CSS up 😅 generally though it looks like the extra-button and search/... aren't in their own container preventing a good space-between. The absence of links seems to cause thsi.
This provides people with the option to choose between the template approach or the classes approach. This is a proposal to tackle #1368 [Preview](https://graphql-7w0ort26u-the-graph-ql-foundation.vercel.app/) This has been applied throughout the codebase now, however one of the things I am uncertain about is how we offer `buildSchema` with the GraphQLDefer/... directives? Should we add an option to `buildSchema`? The exports defined in that chapter seem to only exist in v17 so we should explicitly flag that.
Following typescript documentation, it's not possible override interface property, we can only add new props. Since it's declared as unknown dict, even if we merge `GraphQLErrorExtensions`, we can't access to our extensions without workaround and verbose typescript in source-code. It's annoying since apollo expose `GraphQLFormattedError` instead `GraphQLError` Refs: https://www.typescriptlang.org/docs/handbook/declaration-merging.html Refs: apollographql/apollo-client#11789
Backports #4251 from v17 Backporting this so we can document the `maxTokens` for production use cases. The performance of this change looks to be neutral
Backports #4228 from v17
Currently input-unions and by extension the `@oneOf` directive aren't present in the documentation. I have opted to put this into the advanced section. The copy might be up for improvement, honestly fire away if there's more cases to cover, just wanted to get the ball rolling here. CC @benjie --------- Co-authored-by: Benjie <[email protected]>
CC @dimaMachina Is it possible for the sidebar on `api-v16` to restart? currently it inherits the root one
This is popular on google as an index page
Co-authored-by: Jovi De Croock <[email protected]>
This replaces our expensive method that changes the underlying V8 shape multiple times with a loop that preserves the identity as much as possible. ``` ⏱ Print kitchen sink document 1 tests completed. 2 tests completed. HEAD x 9,290 ops/sec ±0.21% x 1.51 KB/op (24 runs sampled) BASE x 2,645 ops/sec ±0.18% x 2.18 KB/op (11 runs sampled) ``` --------- Co-authored-by: Benjie <[email protected]>
See graphql/graphql.github.io#1951 For someone following the tutorial they may well get as far as running the server (`node server.js`) and then attempt to visit their new API and get confused because they're met with an error such as `{"errors":[{"message":"Missing query"}]}`. This PR adds some joining text to make it clear this is the expected outcome, and they must read on to get the GraphiQL IDE set up so that they can write queries.
…4343) * removes extra parenthesis from getting started code snippet
Co-authored-by: Yaacov Rydzinski <[email protected]>
See: [Archived repo](https://github.com/html5rocks/www.html5rocks.com/blob/master/content/tutorials/es6/promises/en/index.html#L6) redirected the links.
Issue The server throws an error because the root variable is not defined. The correct variable name should be rootValue, which was previously declared in the code. Fix Updated rootValue in the createHandler function to use the correct variable name. Changes Replaced root with rootValue in the GraphQL handler configuration.
…#4363) In the spec we explicitly disallow `nullable` variables to be passed to the fields of a oneOf input object. This is present in v17 but seems missing from v16.
…4366) This PR add `executionOptions` property to the `ExecutionArgs`. Currently only one option can be configured, as is the one I need, but I have built an object so it can easily be extended in the future. The property allows the configuration of the maximum number of errors (`maxErrors`) for coercion. This allows the current hardcoded limit (`50`) to be reduced to a small number to avoid possible DoS attacks. > Also, it updates the execution docs to reflect this new change. I think the documentation was outdated since functions were using positional arguments and now they only accept an object. No longer updates the docs.
Attempting to fix all our failing actions
This refactors the code-first examples to use inline-resolvers rather than the root-value to show a difference between SDL and code-first.
Follow up to #4378
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )