release: on branch next

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated.

Releases

@apollo/[email protected]

Minor Changes

• Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#2657)

  Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
  schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
  provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
  production environment.

  A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

• Includes an optional Schema Coordinate field in the Composition Hints returned by composition (#2658)

• For CoreSpecDefintions that opt in, we've added the ability to tie the core spec version to a particular federation version. That means that if there's a new version of, say, the join spec, you won't necessarily get the new version in the supergraph schema if no subgraph requires it. (#2528)

• Introduce the new @authenticated directive for composition (#2644)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @authenticated directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @authenticated applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables authenticated access to specific types and fields via directive applications.

  The directive is defined as follows:

  directive @authenticated on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  In order to compose your @authenticated usages, you must update your subgraph's federation spec version to v2.5 and add the @authenticated import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@authenticated"])

• Introduce the new @requiresScopes directive for composition (#2649)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @requiresScopes directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @requiresScopes applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables scoped access to specific types and fields via directive applications.

  The directive is defined as follows:

  scalar federation__Scope
  
  directive @requiresScopes(scopes: [federation__Scope!]!) on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  The Scope scalar is effectively a String, similar to the FieldSet type.

  In order to compose your @requiresScopes usages, you must update your subgraph's federation spec version to v2.5 and add the @requiresScopes import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@requiresScopes"])

Patch Changes

• Updated dependencies [fe1e3d7b, 6b18af50, 9396c0d6, 2b5796a9, 4f3c3b9e]:
  • @apollo/[email protected]
  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#2657)

  Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
  schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
  provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
  production environment.

  A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

• Support responses from subgraphs which use the application/graphql-response+json content-type header. (#2162)

  See graphql-over-http spec for more details:
  https://graphql.github.io/graphql-over-http/draft/#sec-application-graphql-response-json

• Introduce the new @authenticated directive for composition (#2644)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @authenticated directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @authenticated applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables authenticated access to specific types and fields via directive applications.

  The directive is defined as follows:

  directive @authenticated on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  In order to compose your @authenticated usages, you must update your subgraph's federation spec version to v2.5 and add the @authenticated import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@authenticated"])

• Introduce the new @requiresScopes directive for composition (#2649)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @requiresScopes directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @requiresScopes applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables scoped access to specific types and fields via directive applications.

  The directive is defined as follows:

  scalar federation__Scope
  
  directive @requiresScopes(scopes: [federation__Scope!]!) on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  The Scope scalar is effectively a String, similar to the FieldSet type.

  In order to compose your @requiresScopes usages, you must update your subgraph's federation spec version to v2.5 and add the @requiresScopes import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@requiresScopes"])

Patch Changes

• Updated dependencies [fe1e3d7b, aac2893a, 6b18af50, 9396c0d6, 2b5796a9, 4f3c3b9e]:
  • @apollo/[email protected]
  • @apollo/[email protected]
  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#2657)

  Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
  schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
  provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
  production environment.

  A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

• For CoreSpecDefintions that opt in, we've added the ability to tie the core spec version to a particular federation version. That means that if there's a new version of, say, the join spec, you won't necessarily get the new version in the supergraph schema if no subgraph requires it. (#2528)

• Introduce the new @authenticated directive for composition (#2644)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @authenticated directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @authenticated applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables authenticated access to specific types and fields via directive applications.

  The directive is defined as follows:

  directive @authenticated on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  In order to compose your @authenticated usages, you must update your subgraph's federation spec version to v2.5 and add the @authenticated import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@authenticated"])

• Refactor/cleanup code that extract subgraphs schema from the supergraph during query planning. (#2655)

• Introduce the new @requiresScopes directive for composition (#2649)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @requiresScopes directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @requiresScopes applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables scoped access to specific types and fields via directive applications.

  The directive is defined as follows:

  scalar federation__Scope
  
  directive @requiresScopes(scopes: [federation__Scope!]!) on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  The Scope scalar is effectively a String, similar to the FieldSet type.

  In order to compose your @requiresScopes usages, you must update your subgraph's federation spec version to v2.5 and add the @requiresScopes import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@requiresScopes"])

@apollo/[email protected]

Minor Changes

• Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#2657)

  Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
  schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
  provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
  production environment.

  A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

Patch Changes

• Updated dependencies [fe1e3d7b, 6b18af50, 9396c0d6, 2b5796a9, 4f3c3b9e]:
  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#2657)

  Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
  schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
  provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
  production environment.

  A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

• Introduce the new @requiresScopes directive for composition (#2649)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @requiresScopes directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @requiresScopes applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables scoped access to specific types and fields via directive applications.

  The directive is defined as follows:

  scalar federation__Scope
  
  directive @requiresScopes(scopes: [federation__Scope!]!) on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  The Scope scalar is effectively a String, similar to the FieldSet type.

  In order to compose your @requiresScopes usages, you must update your subgraph's federation spec version to v2.5 and add the @requiresScopes import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@requiresScopes"])

Patch Changes

• Updated dependencies [fe1e3d7b, 6b18af50, 9396c0d6, 2b5796a9, 4f3c3b9e]:
  • @apollo/[email protected]
  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• Introduce the new @authenticated directive for composition (#2644)

  Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @authenticated directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

  Users may now compose @authenticated applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables authenticated access to specific types and fields via directive applications.

  The directive is defined as follows:

  directive @authenticated on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM

  In order to compose your @authenticated usages, you must update your subgraph's federation spec version to v2.5 and add the @authenticated import to your existing imports like so:

  @link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@authenticated"])

Patch Changes

• Updated dependencies [fe1e3d7b, 6b18af50, 9396c0d6, 2b5796a9, 4f3c3b9e]:
  • @apollo/[email protected]

[email protected]

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.