April 26, 2024

@graphql-tools/prisma-loader@8.0.4

Patch Changes

• #6100 4e72868 Thanks @JohanBrorson! - Remove unused dependencies json-stable-stringify and @types/json-stable-stringify.

April 26, 2024

@graphql-tools/delegate@10.0.6

Patch Changes

• af7be09 Thanks @ardatan! - Hotfix: do not use nullable and nonNullable prefixes if field names don't match

April 26, 2024

@graphql-tools/delegate@10.0.5

Patch Changes

• #6091 9bca9e0 Thanks @User, @User! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly.

  Let's say subschema A has the following schema;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String
      email: String
    }

  And let's say the gateway has the following schema instead;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String!
      email: String!
    }

  In this case, the following query is fine for the gateway but for the subschema, it's not;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name # This is non-nullable in the subschema
        email
      }
    }
  }

  So the subgraph will throw based on this rule OverlappingFieldsCanBeMerged

  To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name: _nullable_name # This is non-nullable in the subschema
        email
      }
    }
  }

• #6092 243c353 Thanks @ardatan! - If one of the subgraphs are already able to resolve a nested field as in parent-entity-call example's Category.details from C's Product, resolve it from there instead of using type merging.

  query {
    product {
      category {
        details {
          # This is coming from C's Product, so resolve it from there instead of Type Merging
          id
          name
        }
      }
    }
  }

@graphql-tools/federation@1.1.28

Patch Changes

• #6091 9bca9e0 Thanks @User, @User! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly.

  Let's say subschema A has the following schema;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String
      email: String
    }

  And let's say the gateway has the following schema instead;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String!
      email: String!
    }

  In this case, the following query is fine for the gateway but for the subschema, it's not;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name # This is non-nullable in the subschema
        email
      }
    }
  }

  So the subgraph will throw based on this rule OverlappingFieldsCanBeMerged

  To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name: _nullable_name # This is non-nullable in the subschema
        email
      }
    }
  }

• Updated dependencies [9bca9e0, 9bca9e0, 243c353]:

  • @graphql-tools/stitch@9.2.0
  • @graphql-tools/delegate@10.0.5

@graphql-tools/stitch@9.2.0

Minor Changes

• #6091 9bca9e0 Thanks @User, @User! - New option useNonNullableFieldOnConflict in typeMergingOptions of stitchSchemas

  When you have two schemas like below, you will get a warning about the conflicting fields because name field is defined as non-null in one schema and nullable in the other schema, and non-nullable field can exist in the stitched schema because of the order or any other reasons, and this might actually cause an unexpected behavior when you fetch User.name from the one who has it as non-nullable.
  This option supresses the warning, and takes the field from the schema that has it as non-nullable.

    type Query {
  
    }
  
    type User {
      id: ID!
      name: String
      email: String
    }

  And;

    type Query {
  
    }
  
    type User {
      id: ID!
      name: String!
    }

Patch Changes

• #6091 9bca9e0 Thanks @User, @User! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly.

  Let's say subschema A has the following schema;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String
      email: String
    }

  And let's say the gateway has the following schema instead;

    type Query {
  
    }
  
    interface User {
      id: ID!
      name: String!
    }
  
    type Admin implements User {
      id: ID!
      name: String!
      role: String!
    }
  
    type Customer implements User {
      id: ID!
      name: String!
      email: String!
    }

  In this case, the following query is fine for the gateway but for the subschema, it's not;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name # This is non-nullable in the subschema
        email
      }
    }
  }

  So the subgraph will throw based on this rule OverlappingFieldsCanBeMerged

  To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

  query {
    user {
      ... on Admin {
        id
        name # This is nullable in the subschema
        role
      }
      ... on Customer {
        id
        name: _nullable_name # This is non-nullable in the subschema
        email
      }
    }
  }

• #6092 243c353 Thanks @ardatan! - If one of the subgraphs are already able to resolve a nested field as in parent-entity-call example's Category.details from C's Product, resolve it from there instead of using type merging.

  query {
    product {
      category {
        details {
          # This is coming from C's Product, so resolve it from there instead of Type Merging
          id
          name
        }
      }
    }
  }

• Updated dependencies [9bca9e0, 243c353]:

  • @graphql-tools/delegate@10.0.5

April 24, 2024

@graphql-tools/federation@1.1.27

Patch Changes

• #6086 f538e50 Thanks @ardatan! - Handle @inaccessible types correctly

April 24, 2024

@graphql-tools/stitch@9.1.2

Patch Changes

• 6d26702 Thanks @ardatan! - Respect interface types as computed field types

April 24, 2024

@graphql-tools/stitch@9.1.1

Patch Changes

• c5df958 Thanks @ardatan! - Prevent infinite loop while visiting over the computed field types

April 19, 2024

@graphql-tools/batch-delegate@9.0.2

Patch Changes

• #5998 9eee255 Thanks @ardatan! - Add parentType name to the batch delegation key

@graphql-tools/federation@1.1.26

Patch Changes

• #6071 6cf507f Thanks @ardatan! - Handle inaccessible enum values

April 15, 2024

@graphql-tools/utils@10.1.3

Patch Changes

• #6055 4093f70 Thanks @enisdenjo! - Disallow new lines in paths when checking with isValidPath

  A string may sometimes look like a path but is not (like an SDL of a simple
  GraphQL schema). To make sure we don't yield false-positives in such cases,
  we disallow new lines in paths (even though most Unix systems support new
  lines in file names).

April 08, 2024

@graphql-tools/executor@1.2.6

Patch Changes

• #6038 02dd9ac Thanks @ardatan! - Some libraries like undici throw objects that are not Error instances when the response is tried to parse as JSON but failed.
  In that case, executor prints an error like below;

  NonErrorThrown: Unexpected error value: {...}
  at toError (/usr/src/app/node_modules/graphql/jsutils/toError.js:16:7)
  at locatedError (/usr/src/app/node_modules/graphql/error/locatedError.js:20:46)
  at /usr/src/app/node_modules/@graphql-tools/executor/cjs/execution/execute.js:330:58
  at processTicksAndRejections (node:internal/process/task_queues:95:5)
  at async /usr/src/app/node_modules/@graphql-tools/executor/cjs/execution/promiseForObject.js:18:35
  at async Promise.all (index 0)
  

  But actually the shape of the object matches the Error interface.
  In that case, the executor now coerces the object to an Error instance by taking message, stack, name and cause properties.
  So the user will get the error correctly.

April 08, 2024

@graphql-tools/executor-urql-exchange@1.0.2

Patch Changes

• #6023 cfe7727 Thanks @renovate! - dependencies updates:
  • Updated dependency @urql/core@^3.0.0 || ^4.0.0 || ^5.0.0 ↗︎ (from ^3.0.0 || ^4.0.0, in peerDependencies)

@graphql-tools/stitch@9.1.0

Minor Changes

• #5162 27b6f49 Thanks @asodeur! - Adding the ability to return non-scalar types from computed fields. Computed fields can now return
  object types (local or stitched), interfaces, unions, or enums.

@graphql-tools/stitching-directives@3.0.2

Patch Changes

• #5162 27b6f49 Thanks @asodeur! - Adding the ability to return non-scalar types from computed fields. Computed fields can now return
  object types (local or stitched), interfaces, unions, or enums.