Skip to content

Releases: ardatan/graphql-tools

July 03, 2024

03 Jul 21:27
8f6a514
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

July 01, 2024

01 Jul 11:43
0081f3e
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

  • #6306
    74f995f
    Thanks @n1ru4l! - Properly propagate the original error in custom
    scalars.

    Errors thrown in the parseValue function for custom scalars were not propagated correctly using
    the originalError property of the GraphQLError on invalid input. As a result, error codes from
    the extensions.code were not propagated correctly.

  • Updated dependencies
    [66c99d9]:

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

June 21, 2024

21 Jun 21:55
97b312a
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

  • #6280
    7dcd0af
    Thanks @ardatan! - Since the executor is version agnostic, it should
    respect the schemas created with older versions.

    So if a type resolver returns a type instead of type name which is required since graphql@16,
    the executor should handle it correctly.

    See the following example:

    // Assume that the following code is executed with `graphql@15`
    import { execute } from '@graphql-tools/executor'
    
    const BarType = new GraphQLObjectType({
      name: 'Bar',
      fields: {
        bar: {
          type: GraphQLString,
          resolve: () => 'bar'
        }
      }
    })
    const BazType = new GraphQLObjectType({
      name: 'Baz',
      fields: {
        baz: {
          type: GraphQLString,
          resolve: () => 'baz'
        }
      }
    })
    const BarBazType = new GraphQLUnionType({
      name: 'BarBaz',
      types: [BarType, BazType],
      // This is the resolver that returns the type instead of type name
      resolveType(obj) {
        if ('bar' in obj) {
          return BarType
        }
        if ('baz' in obj) {
          return BazType
        }
      }
    })
    const QueryType = new GraphQLObjectType({
      name: 'Query',
      fields: {
        barBaz: {
          type: BarBazType,
          resolve: () => ({ bar: 'bar' })
        }
      }
    })
    const schema = new GraphQLSchema({
      query: QueryType
    })
    
    const result = await execute({
      schema,
      document: parse(/* GraphQL */ `
        query {
          barBaz {
            ... on Bar {
              bar
            }
            ... on Baz {
              baz
            }
          }
        }
      `)
    })
    
    expect(result).toEqual({
      data: {
        barBaz: {
          bar: 'bar'
        }
      }
    })

June 18, 2024

18 Jun 08:22
f61518e
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Minor Changes

  • #6267
    d5dd794
    Thanks @EmrysMyrddin! - Add delayInSeconds to the failure
    event to give users more control on failure handling.

  • #6267
    d5dd794
    Thanks @EmrysMyrddin! - Add a the ability to start polling with
    a delay. This ease the handling of failure handling, allowing to restart the manager and
    respecting GraphOS minimum retry delay.

Patch Changes

  • #6267
    d5dd794
    Thanks @EmrysMyrddin! - Fix Supergraph Manager Event Emitter
    not calling every listener when at least one has been registered using once method.

June 11, 2024

11 Jun 06:28
2d7402e
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

  • #6238
    0f7059b
    Thanks @ardatan! - Merge the elements of the lists if the root field
    is shared across different subgraphs

    type Query {
      products: [Product] # If this field is returned by multiple subgraphs, the elements of the lists will be merged
    }
  • Updated dependencies
    [0f7059b]:

@graphql-tools/[email protected]

Patch Changes

  • #6238
    0f7059b
    Thanks @ardatan! - If the given objects are arrays with the same
    length, merge the elements.

    const a = [{ a: 1 }, { b: 2 }]
    const b = [{ c: 3 }, { d: 4 }]
    const result = mergeDeep(a, b) // [{ a: 1, c: 3 }, { b: 2, d: 4 }]

June 04, 2024

04 Jun 09:54
f4fbc20
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Major Changes

  • #6227
    85c383f
    Thanks @ardatan! - BREAKING: invalidateSupergraph is now replaced
    with invalidateUnifiedGraph

@graphql-tools/[email protected]

Major Changes

  • #6227
    85c383f
    Thanks @ardatan! - BREAKING: invalidateSupergraph is now replaced
    with invalidateUnifiedGraph

Patch Changes

@graphql-tools/[email protected]

Major Changes

  • #6227
    85c383f
    Thanks @ardatan! - BREAKING CHANGES:
    • getSubschemasFromSupergraphSdl has been removed in favor of the new
      getStitchingOptionsFromSupergraphSdl, and it returns the options for stitchSchemas instead
      of the map of subschemas
    • onExecutor has been removed in favor of onSubschemaConfig
    • To change the default HTTP executor options, use httpExecutorOpts instead of onExecutor

Patch Changes

May 27, 2024

27 May 10:28
17530bc
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

  • #6194
    7368829
    Thanks @ardatan! - Handle interface objects in a different way

  • #6188
    e10c13a
    Thanks @ardatan! - Add subtractSelectionSets to get the diff of
    two selection sets

  • #6187
    dfccfbf
    Thanks @ardatan! - Do not merge errors and regular resolved objects

    If a subschema returns an error for specific field that is already resolved by another subschema,
    the error should not be merged with the resolved object.

  • #6189
    0134f7f
    Thanks @ardatan! - Handle interface types with non-shared
    implementations;

    For example, you have the following services, where Node is implemented in both services, but
    Foo and Bar are only implemented in one service. And when the gateway receives the following
    query, it should be converted to this because Node is not implemented as Bar in Service 1
    while implemented in Service 2.

    Query conversion;

    # Gateway request
    query {
      fooBar(id: "1") {
        ... on Node {
          id
        }
      }
    }
    # Service 1 Request
    query {
      fooBar(id: "1") {
        ... on Foo {
          id
        }
        ... on Bar {
          id
        }
      }
    }

    Services;

    # Service 1
    
    union FooBar = Foo | Bar
    
    interface Node {
      id: ID!
    }
    
    type Foo implements Node {
      id: ID!
    }
    
    type Bar {
      id: ID!
    }
    
    type Query {
      fooBar(id: ID!): FooBar
    }
    # Service 2
    interface Node {
      id: ID!
    }
    
    type Foo implements Node {
      id: ID!
    }
    
    type Bar implements Node {
      id: ID!
    }
  • Updated dependencies
    [7368829,
    e10c13a]:

@graphql-tools/[email protected]

Patch Changes

  • #6194
    7368829
    Thanks @ardatan! - Handle interface objects in a different way

  • #6189
    0134f7f
    Thanks @ardatan! - Handle interface types with non-shared
    implementations;

    For example, you have the following services, where Node is implemented in both services, but
    Foo and Bar are only implemented in one service. And when the gateway receives the following
    query, it should be converted to this because Node is not implemented as Bar in Service 1
    while implemented in Service 2.

    Query conversion;

    # Gateway request
    query {
      fooBar(id: "1") {
        ... on Node {
          id
        }
      }
    }
    # Service 1 Request
    query {
      fooBar(id: "1") {
        ... on Foo {
          id
        }
        ... on Bar {
          id
        }
      }
    }

    Services;

    # Service 1
    
    union FooBar = Foo | Bar
    
    interface Node {
      id: ID!
    }
    
    type Foo implements Node {
      id: ID!
    }
    
    type Bar {
      id: ID!
    }
    
    type Query {
      fooBar(id: ID!): FooBar
    }
    # Service 2
    interface Node {
      id: ID!
    }
    
    type Foo implements Node {
      id: ID!
    }
    
    type Bar implements Node {
      id: ID!
    }
  • #6187
    dfccfbf
    Thanks @ardatan! - Respect @provides to optimize the query plan

  • #6188
    e10c13a
    Thanks @ardatan! - If two different subschemas have the root field,
    use the same field to resolve missing fields instead of applying a type merging in advance

  • Updated dependencies
    [7368829,
    e10c13a,
    e10c13a,
    dfccfbf,
    0134f7f,
    eec9d3d,
    03a47b1,
    e10c13a,
    0827497]:

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

  • #6194
    7368829
    Thanks @ardatan! - Handle interface objects in a different way

  • #6180
    eec9d3d
    Thanks @ardatan! - Handle nested dependencies in the computed fields

    {
      merge: {
        Product: {
          selectionSet: '{ id }',
          fields: {
            isExpensive: {
              selectionSet: '{ price }',
              computed: true,
            },
            canAfford: {
              selectionSet: '{ isExpensive }',
              computed: true,
            },
          }
        }
      }
    }
  • #6179
    03a47b1
    Thanks @ardatan! - Support computed fields resolved via a root field
    returning an interface When a computed field returning an object, and that field is resolved via
    an interface, the computed field will now be resolved correctly.

  • [#6188](https://github.com/ardatan/graphql-tools/pul...

Read more

May 14, 2024

14 May 21:59
0161fc1
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

@graphql-tools/[email protected]

Patch Changes

May 08, 2024

08 May 11:32
876f03a
Compare
Choose a tag to compare

@graphql-tools/[email protected]

Patch Changes

  • #6134 a83da08 Thanks @User! - Ignore unmerged fields

    Let's say you have a gateway schema like in the bottom, and id is added to the query, only if the age is requested;

    # This will be sent as-is
    {
      user {
        name
      }
    }

    But the following will be transformed;

    {
      user {
        name
        age
      }
    }

    Into

    {
      user {
        id
        name
        age
      }
    }
type Query {

}

type User {
  id: ID! # is the key for all services
  name: String!
  age: Int! # This comes from another service
}
  • #6150 fc9c71f Thanks @ardatan! - If there are some fields depending on a nested type resolution, wait until it gets resolved then resolve the rest.

    See packages/federation/test/fixtures/complex-entity-call example for more details.
    You can see ProductList needs some fields from Product to resolve first

@graphql-tools/[email protected]

Patch Changes

  • #6141 cd962c1 Thanks @ardatan! - When the gateway receives the query, now it chooses the best root field if there is the same root field in different subgraphs.
    For example, if there is node(id: ID!): Node in all subgraphs but one implements User and the other implements Post, the gateway will choose the subgraph that implements User or Post based on the query.

    If there is a unresolvable interface field, it throws.

    See this supergraph and the test query to see a real-life example

  • #6143 04d5431 Thanks @ardatan! - Implement interface objects support

  • Updated dependencies [a83da08, fc9c71f, cd962c1]:

@graphql-tools/[email protected]

Patch Changes

  • #6134 a83da08 Thanks @User! - Ignore unmerged fields

    Let's say you have a gateway schema like in the bottom, and id is added to the query, only if the age is requested;

    # This will be sent as-is
    {
      user {
        name
      }
    }

    But the following will be transformed;

    {
      user {
        name
        age
      }
    }

    Into

    {
      user {
        id
        name
        age
      }
    }
type Query {

}

type User {
  id: ID! # is the key for all services
  name: String!
  age: Int! # This comes from another service
}
  • #6150 fc9c71f Thanks @ardatan! - If there are some fields depending on a nested type resolution, wait until it gets resolved then resolve the rest.

    See packages/federation/test/fixtures/complex-entity-call example for more details.
    You can see ProductList needs some fields from Product to resolve first

  • #6141 cd962c1 Thanks @ardatan! - When the gateway receives the query, now it chooses the best root field if there is the same root field in different subgraphs.
    For example, if there is node(id: ID!): Node in all subgraphs but one implements User and the other implements Post, the gateway will choose the subgraph that implements User or Post based on the query.

    If there is a unresolvable interface field, it throws.

    See this supergraph and the test query to see a real-life example

  • Updated dependencies [a83da08, fc9c71f]:

May 02, 2024

02 May 16:50
ecc39c7
Compare
Choose a tag to compare