Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update apollo graphql packages #2704

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Mar 10, 2023

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@apollo/gateway (source) 2.8.5 -> 2.9.3 age adoption passing confidence
@apollo/server (source) 4.9.3 -> 4.11.2 age adoption passing confidence
@apollo/server-plugin-landing-page-graphql-playground (source) 4.0.0 -> 4.0.1 age adoption passing confidence
@apollo/server-plugin-response-cache (source) 4.1.0 -> 4.1.3 age adoption passing confidence
@apollo/subgraph (source) 2.2.3 -> 2.9.3 age adoption passing confidence

Release Notes

apollographql/federation (@​apollo/gateway)

v2.9.3

Compare Source

Patch Changes

v2.9.2

Compare Source

Patch Changes

v2.9.1

Compare Source

Patch Changes

v2.9.0

Compare Source

Patch Changes
apollographql/apollo-server (@​apollo/server)

v4.11.2

Compare Source

(No change; there is a change to the @apollo/server-integration-testsuite used to test integrations, and the two packages always have matching versions.)

v4.11.1

Compare Source

Patch Changes
  • #​7952 bb81b2c Thanks @​glasser! - Upgrade dependencies so that automated scans don't detect a vulnerability.

    @apollo/server depends on express which depends on cookie. Versions of express older than v4.21.1 depend on a version of cookie vulnerable to CVE-2024-47764. Users of older express versions who call res.cookie() or res.clearCookie() may be vulnerable to this issue.

    However, Apollo Server does not call this function directly, and it does not expose any object to user code that allows TypeScript users to call this function without an unsafe cast.

    The only way that this direct dependency can cause a vulnerability for users of Apollo Server is if you call startStandaloneServer with a context function that calls Express-specific methods such as res.cookie() or res.clearCookies() on the response object, which is a violation of the TypeScript types provided by startStandaloneServer (which only promise that the response object is a core Node.js http.ServerResponse rather than the Express-specific subclass). So this vulnerability can only affect Apollo Server users who use unsafe JavaScript or unsafe as typecasts in TypeScript.

    However, this upgrade will at least prevent vulnerability scanners from alerting you to this dependency, and we encourage all Express users to upgrade their project's own express dependency to v4.21.1 or newer.

v4.11.0

Compare Source

Minor Changes
  • #​7916 4686454 Thanks @​andrewmcgivery! - Add hideSchemaDetailsFromClientErrors option to ApolloServer to allow hiding 'did you mean' suggestions from validation errors.

    Even with introspection disabled, it is possible to "fuzzy test" a graph manually or with automated tools to try to determine the shape of your schema. This is accomplished by taking advantage of the default behavior where a misspelt field in an operation
    will be met with a validation error that includes a helpful "did you mean" as part of the error text.

    For example, with this option set to true, an error would read Cannot query field "help" on type "Query". whereas with this option set to false it would read Cannot query field "help" on type "Query". Did you mean "hello"?.

    We recommend enabling this option in production to avoid leaking information about your schema to malicious actors.

    To enable, set this option to true in your ApolloServer options:

    const server = new ApolloServer({
      typeDefs,
      resolvers,
      hideSchemaDetailsFromClientErrors: true,
    });

v4.10.5

Compare Source

Patch Changes

v4.10.4

Compare Source

Patch Changes
  • #​7871 18a3827 Thanks @​tninesling! - Subscription heartbeats are initialized prior to awaiting subscribe(). This allows long-running setup to happen in the returned Promise without the subscription being terminated prior to resolution.

v4.10.3

Compare Source

Patch Changes
  • #​7866 5f335a5 Thanks @​tninesling! - Catch errors thrown by subscription generators, and gracefully clean up the subscription instead of crashing.

v4.10.2

Compare Source

Patch Changes
  • #​7849 c7e514c Thanks @​TylerBloom! - In the subscription callback server plugin, terminating a subscription now immediately closes the internal async generator. This avoids that generator existing after termination and until the next message is received.

v4.10.1

Compare Source

Patch Changes
  • #​7843 72f568e Thanks @​bscherlein! - Improves timing of the willResolveField end hook on fields which return Promises resolving to Arrays. This makes the use of the setCacheHint method more reliable.

v4.10.0

Compare Source

Minor Changes
  • #​7786 869ec98 Thanks @​ganemone! - Restore missing v1 skipValidation option as dangerouslyDisableValidation. Note that enabling this option exposes your server to potential security and unexpected runtime issues. Apollo will not support issues that arise as a result of using this option.

  • #​7803 e9a0d6e Thanks @​favna! - allow stringifyResult to return a Promise<string>

    Users who implemented the stringifyResult hook can now expect error responses to be formatted with the hook as well. Please take care when updating to this version to ensure this is the desired behavior, or implement the desired behavior accordingly in your stringifyResult hook. This was considered a non-breaking change as we consider that it was an oversight in the original PR that introduced stringifyResult hook.

Patch Changes

v4.9.5

Compare Source

Patch Changes

v4.9.4

Compare Source

Patch Changes
  • #​7747 ddce036e1 Thanks @​trevor-scheer! - The minimum version of graphql officially supported by Apollo Server 4 as a peer dependency, v16.6.0, contains a serious bug that can crash your Node server. This bug is fixed in the immediate next version, [email protected], and we strongly encourage you to upgrade your installation of graphql to at least v16.7.0 to avoid this bug. (For backwards compatibility reasons, we cannot change Apollo Server 4's minimum peer dependency, but will change it when we release Apollo Server 5.)

    Apollo Server 4 contained a particular line of code that makes triggering this crashing bug much more likely. This line was already removed in Apollo Server v3.8.2 (see #​6398) but the fix was accidentally not included in Apollo Server 4. We are now including this change in Apollo Server 4, which will reduce the likelihood of hitting this crashing bug for users of graphql v16.6.0. That said, taking this @apollo/server upgrade does not prevent this bug from being triggered in other ways, and the real fix to this crashing bug is to upgrade graphql.

apollographql/apollo-server (@​apollo/server-plugin-landing-page-graphql-playground)

v4.0.1

Compare Source

Patch Changes
apollographql/apollo-server (@​apollo/server-plugin-response-cache)

v4.1.3

Compare Source

Patch Changes
  • #​7614 4fadf3ddc Thanks @​Cellule! - Publish TypeScript typings for CommonJS modules output.

    This allows TypeScript projects that use CommonJS modules with
    moduleResolution: "node16" or
    moduleResolution: "nodeNext"
    to correctly resolves the typings of apollo's packages as CommonJS instead of ESM.

v4.1.2

Compare Source

Patch Changes

v4.1.1

Compare Source

Patch Changes
apollographql/federation (@​apollo/subgraph)

v2.9.3

Compare Source

Patch Changes

v2.9.2

Compare Source

Patch Changes

v2.9.1

Compare Source

Patch Changes

v2.9.0

Compare Source

Patch Changes

v2.8.5

Compare Source

Patch Changes

v2.8.4

Compare Source

Patch Changes

v2.8.3

Compare Source

Patch Changes

v2.8.2

Compare Source

Patch Changes

v2.8.1

Compare Source

Patch Changes

v2.8.0

Compare Source

Patch Changes

v2.7.8

Compare Source

Patch Changes

v2.7.7

Compare Source

Patch Changes

v2.7.6

Compare Source

Patch Changes

v2.7.5

Compare Source

Patch Changes

v2.7.4

Compare Source

Patch Changes

v2.7.3

Compare Source

Patch Changes

v2.7.2

Compare Source

Patch Changes

v2.7.1

Compare Source

Patch Changes

v2.7.0

Compare Source

Minor Changes
  • Implement progressive @override functionality (#​2911)

    The progressive @override feature brings a new argument to the @override directive: label: String. When a label is added to an @override application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only.

    Out-of-the-box, the router will support a percentage-based use case for progressive @override. For example:

    type Query {
      hello: String @&#8203;override(from: "original", label: "percent(5)")
    }

    The above example will override the root hello field from the "original" subgraph 5% of the time.

    More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service).

Patch Changes

v2.6.3

Compare Source

Patch Changes

v2.6.2

Compare Source

Patch Changes

v2.6.1

Compare Source

Patch Changes

v2.6.0

Compare Source

Patch Changes

v2.5.7

Compare Source

Patch Changes

v2.5.6

Compare Source

Patch Changes

v2.5.5

Compare Source

Patch Changes
  • Fix specific case for requesting __typename on interface entity type (#​2775)

    In certain cases, when resolving a __typename on an interface entity (due to it actual being requested in the operation), that fetch group could previously be trimmed / treated as useless. At a glance, it appears to be a redundant step, i.e.:

    { ... on Product { __typename id }} => { ... on Product { __typename} }
    

    It's actually necessary to preserve this in the case that we're coming from an interface object to an (entity) interface so that we can resolve the concrete __typename correctly.

  • Updated dependencies []:

v2.5.4

Compare Source

Patch Changes

v2.5.3

Compare Source

Patch Changes

v2.5.2

Compare Source

Patch Changes

v2.5.1

Compare Source

Patch Changes

v2.5.0

Compare Source

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 @&#8203;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:

    @&#8203;link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@&#8203;authenticated"])
Patch Changes

v2.4.13

Compare Source

Patch Changes

v2.4.12

Compare Source

Patch Changes

v2.4.11

Compare Source

Patch Changes

v2.4.10

Compare Source

Patch Changes

v2.4.9

Compare Source

Patch Changes

v2.4.8

Compare Source

Patch Changes

v2.4.7

Compare Source

Patch Changes

v2.4.6

Compare Source

Patch Changes

v2.4.5

Compare Source

Patch Changes

v2.4.4

Compare Source

Patch Changes

v2.4.3

Compare Source

Patch Changes
  • Resolve Promise references before calling __resolveType on interface (#​2556)

    Since the introduction of entity interfaces, users could not return
    a Promise from __resolveReference while implementing a synchronous,
    custom __resolveType function. This change fixes/permits this use case.

    Additional background / implementation details:

    Returning a Promise from __resolveReference has historically never
    been an issue. However, with the introduction of entity interfaces, the
    calling of an interface's __resolveType function became a new concern.

    __resolveType functions expect a reference (and shouldn't be concerned
    with whether those references are wrapped in a Promise). In order to
    address this, we can await the reference before calling the
    __resolveType (this handles both the non-Promise and Promise case).

  • Updated dependencies [f6a8c1ce]:

v2.4.2

Compare Source

Patch Changes

v2.4.1

Compare Source

Patch Changes
  • Updated dependencies [

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the dependencies Pull requests that update a dependency file label Mar 10, 2023
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 0b1e8d2 to 5e7c46c Compare March 10, 2023 12:18
@kamilmysliwiec
Copy link
Member

@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from 4251eb8 to 3fe8a8a Compare March 10, 2023 19:05
@renovate renovate bot changed the title chore(deps): update dependency @apollo/subgraph to v2.3.3 chore(deps): update apollo graphql packages Mar 10, 2023
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 15 times, most recently from 155b213 to c868a7c Compare March 17, 2023 17:14
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 8 times, most recently from b3e30ed to 2c8cf77 Compare March 21, 2023 16:14
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 03475e2 to 66fe20b Compare June 18, 2024 19:00
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from d921923 to 76138d1 Compare July 2, 2024 07:54
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 76138d1 to 6b2e33f Compare July 13, 2024 01:54
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 839c0e0 to cfe33fd Compare July 25, 2024 23:26
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from cfe33fd to b478cec Compare August 8, 2024 17:49
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 8d2ceb1 to 5698bd3 Compare August 27, 2024 18:16
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 5698bd3 to d061cfe Compare September 18, 2024 00:53
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from d061cfe to 67f3b56 Compare September 27, 2024 07:11
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 67f3b56 to cb466c4 Compare October 6, 2024 18:07
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 6 times, most recently from 7bc473c to bd30383 Compare October 23, 2024 08:48
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from bedab39 to 88c0278 Compare November 5, 2024 13:38
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 88c0278 to 14b87df Compare November 12, 2024 16:43
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from 89759c1 to eddd355 Compare November 27, 2024 14:21
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 2f42034 to 7ce025b Compare December 3, 2024 12:17
@renovate renovate bot force-pushed the renovate/apollo-graphql-packages branch from 7ce025b to 08d827b Compare December 9, 2024 12:50
@renovate renovate bot changed the title chore(deps): update apollo graphql packages fix(deps): update apollo graphql packages Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants