v0.0.13

Patch Changes

• 6151cdb: Add all valid input types to ExecutorSchema

  Variables can define ad-hoc input types not present in schema by adding non-null wrappers.

v0.0.12

Patch Changes

• d93aa9a: Add graphql-js v14 support

• 832b8af: Introduce the ExecutorSchema interface

  graphql-executor "upgrades" GraphQLSchema objects created with graphql-js v14 and v15 to a graphql-js v16-compatibile version by providing utility functions that analyze the schema and provide all the necessary metadata. This change introduces the the ExecutorSchema interface so that clients can explicitly perform this schema preparation step.

  The included (memoized) toExectorSchema utility function generates an ExecutorSchema from a GraphQLSchema object and is called implicitly if only a GraphQLSchema is passed to the executor. Using the new executorSchema option, however, a pre-specified ExecutorSchema instance can be used. In this case, the GraphQLSchema passed via the schema option is never used by graphql-executor and only required so that it can be passed through to resolvers via the info argument.

  The ExecutorSchema is also passed to resolvers within an executorSchema property added to the info argument (using TypeScript interface merging). This property is populated both when the ExecutorSchema is provided explicitly and when it is generated from the GraphQLSchema.

  BREAKING CHANGE:

  The Executor class is now instantiated with an configuration object containing a schema of type GraphQLSchema and an optional executorSchema of type ExecutorSchema. Previously, the executor was instantiated without any parameters.

  NOTE:

  When the executor is instantiated with both a schema and an executorSchema:

  1. graphql-executor does not validate the schema or executorSchema.
  2. graphql-executor does not check whether the executorSchema matches the schema.
  3. graphql-executor does not utilize the schema in any way except to pass its value to resolvers as a property of the info argument.

• ac0430a: remove createSourceEventStream function export

  BREAKING CHANGE: access to createSourceEventStream is still possible in advanced cases, but now only via an explicitly created instance of the internal Executor class.

• d06133c: Skip schema validation prior to first use.

  Schemas can (and should!) still be validated when and where appropriate using the dedicated graphql-js validateSchema method.

  graphql-js validates previously unvalidated schemas prior to the first execution. The validation step is skipped by graphql-js if and only if the schema was created with the assumeValid option, which essentially triggers a faux validation run that produces no errors.

  graphql-executor now simply does not automatically validate schemas, preferring to require servers to explicitly validate schemas when and where appropriate, just as document validation is a distinct, explicit step.

• ecc3758: Allow cross-realm execution

  This is made possible by avoiding instanceof checks within the executor proper.

  New predicates are introduced that rely on Symbol.toStringTag (or error names) to identify objects from other realms.

  Field/type resolvers and isTypeOf functions that are passed GraphQL type system entities and use native graphql-js predicates will still encounter cross-realm errors.

  Cross-realm execution can be avoided by end-users by simply calling the original isSchema predicate from graphql-js.

v0.0.11

Patch Changes

• c598a40: Release latest upstream incremental delivery changes

  At most recent working group, decisions were made (1) to throw field errors on negative "initialCount" arguments to the "stream" directive, (2) to forbid deferral of non-Query root fields.

  Implementation of disabling of incremental delivery is done upstream on schema creation, we continue to use the disableIncremental argument on execution, as graphql-executor does not manage schema creation.

v0.0.10

Patch Changes

• 5a9c3be: Update README.md to reflect integration of execute and subscribe

v0.0.9

Patch Changes

• 797ee21: Memoize field lists created by the collectFields utility function.

  This allows functions that operate on these field lists to be memoized.

• 79440e6: Re-implement incremental delivery using repeaters.

  See https://repeater.js.org/ for further discussion about repeaters. This avoids bespoke raw async iterator and promise racing implementations.

• 3bd508d: Refactor flattenAsyncIterator to use a Repeater implementation

  This is also breaking change as the generator returned by flattenAsyncIterator will now (correctly) not support concurrent next() and throw() calls. As the generator returned by calls to execute should rarely be used with throw(), this breaking change should have little impact.

• 6bb42ab: Refactor mapAsyncIterator to use a Repeater implementation

  This is a breaking change as the generator returned by mapAsyncIterator will now (correctly) not support concurrent next() and throw() calls. As the generator returned by calls to execute should rarely be used with throw(), this breaking change should have little impact.

• f6d0b73: Support incremental delivery with defer/stream directives

  Port of graphql#2839
  defer/stream support is enabled by default, but can be disabled using the disableIncremental argument.

• 7aaffa2: BREAKING CHANGE: execute now executes subscriptions as subscriptions, not queries, unless the new forceQueryAlgorithm option is set to true. The subscribe function has been removed.

  Executing a subscription with improper arguments now throws an error (rather than returning a promise that rejects with an error), aligning execution of subscriptions to that of queries and mutations.

v0.0.8

Patch Changes

• 8df89b5: Allow list field resolvers to return async iterables

  graphql#2757

v0.0.7

Patch Changes

• 6188539: Use custom Promise.all implementation

  The GraphQL specification allows fields and list items to execute in parallel (except the root fields of a mutation operation). Node.JS does not actually allow true parallel threads of execution, but it can approach the performance benefit using asynchronous code and the event loop. In practice, returning a result containing asynchronous work uses the built in Node.JS Promise.all method, which awaits the results of all pending work prior to returning.

  In a case where completion of a field or list item value errors (i.e. the resolver returned an error, and the field or list item value is not nullable), the current implementation exits early, as only one error is returned to the client per field, as per the spec. This can lead to undetectable long-running promises on the server. The new implementation waits for all promises to settle, but does not use Promise.allSettled, in order to ensure that the first error to occur is always returned, even if there are multiple errors. See also graphql#2974

  On success, the new implementation also modifies the existing object, rather than returning a new object, in order to improve performance.

• 4e571e7: Switch graphql-js to peer dependency

v0.0.6

Patch Changes

• 43faf00: Update dependencies.

v0.0.5

Patch Changes

• 604d928: Re-export execution functions

  graphql-executor previously allowed for execution pipeline customization by subclassing the exported Executor function. However, the existence of graphql-executor as a "safe," "smart" fork of graphql-js also allows for customization of the execution pipeline by simply forking graphql-executor, customizing, and using the execute and subscribe functions. These functions are now exported for that purpose. See the updated package README for further discussion.

v0.0.4

Patch Changes

• 8016954: Add GraphQL v15 to supported versions
• 8016954: Add changesets for workflow management