chore(deps-dev): bump @apollo/server from 4.5.0 to 4.6.0

[dependabot]

Bumps @apollo/server from 4.5.0 to 4.6.0.

Release notes

Sourced from @​apollo/server's releases.

@​apollo/server-integration-testsuite@​4.6.0

Patch Changes

• #7454 f6e3ae021 Thanks @​trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• Updated dependencies [1e808146a, f6e3ae021, e0db95b96]:

  • @​apollo/server@​4.6.0

@​apollo/server@​4.6.0

Minor Changes

• #7465 1e808146a Thanks @​trevor-scheer! - Introduce new opt-in configuration option to mitigate v4 status code regression

  Apollo Server v4 accidentally started responding to requests with an invalid variables object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users.

  new ApolloServer({
    // ...
    status400ForVariableCoercionErrors: true,
  });

  Specifically, this regression affects cases where input variable coercion fails. Variables of an incorrect type (i.e. String instead of Int) or unexpectedly null are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the GraphQL spec.

  This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed.

Patch Changes

• #7454 f6e3ae021 Thanks @​trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• #7433 e0db95b96 Thanks @​KGAdamCook! - Previously, when users provided their own documentStore, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so.

Changelog

Sourced from @​apollo/server's changelog.

4.6.0

Minor Changes

• #7465 1e808146a Thanks @​trevor-scheer! - Introduce new opt-in configuration option to mitigate v4 status code regression

  Apollo Server v4 accidentally started responding to requests with an invalid variables object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users.

  new ApolloServer({
    // ...
    status400ForVariableCoercionErrors: true,
  });

  Specifically, this regression affects cases where input variable coercion fails. Variables of an incorrect type (i.e. String instead of Int) or unexpectedly null are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the GraphQL spec.

  This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed.

Patch Changes

• #7454 f6e3ae021 Thanks @​trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• #7433 e0db95b96 Thanks @​KGAdamCook! - Previously, when users provided their own documentStore, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so.

Commits

• 05b2da4 Version Packages (#7473)
• e0db95b fix: updated documentstore to use schema hash (#7433)
• f6e3ae0 Upgrade to TypeScript 5.x (#7454)
• 1e80814 fix: Introduce status code regression mitigation (#7465)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[coveralls]

Pull Request Test Coverage Report for Build c720e40c-5917-49db-9c76-fad19dd7279d

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 92.656%

---

Totals
Change from base Build f5bc18da-315b-421d-974d-331e8f0b5f71:	0.0%
Covered Lines:	6498
Relevant Lines:	7013

---

💛 - Coveralls