Bump apollo-server from 2.16.1 to 2.25.3 in /SimpleUploadServer

[dependabot]

Bumps apollo-server from 2.16.1 to 2.25.3.

Changelog

Sourced from apollo-server's changelog.

v2.25.3

• ⚠️ SECURITY apollo-server-core: Update default version of the GraphQL Playground React app loaded from the CDN to be @apollographql/[email protected]. This patches an XSS vulnerability. Note that if you are pinning the Playground React app version in your app with new ApolloServer({playground: {version: 'some version'}}), you will need to update the specified version to 1.7.42 or later to avoid this vulnerability. If you disable GraphQL Playground with new ApolloServer({playground: false}), this vulnerability does not affect you. See advisory GHSA-qm7x-rc44-rrqw for more details.

v2.25.2

• apollo-server-express: Update dependencies on @types/express and @types/express-serve-static-core. [PR #5352](apollographql/apollo-server#5352)

v2.25.1

• apollo-server-core, apollo-server-express: Upgrade subscriptions-transport-ws dependency and remove unneeded runtime dependency on ws. This should enable you to install Apollo Server without depending on versions of ws vulnerable to CVE-2021-32640. Note that the superficial integration of the unmaintained subscriptions-transport-ws package will be removed in Apollo Server 3; you can also avoid this vulnerability by disabling the built-in subscription support with new ApolloServer({subscriptions: false}) and using a maintained package such as graphql-ws instead. (Instead of taking this upgrade, you can also upgrade ws to 5.2.3, which was just released.)

v2.25.0

• apollo-server-core: You may now specify your Studio graph as a graph ref (id@variant) via the APOLLO_GRAPH_REF environment variable or new ApolloServer({apollo: {graphRef}}) instead of specifying graph ID and graph variant separately. The apollo object passed to plugin serverWillStart and to gateway load now contains a graphRef field.
• apollo-server-core: Fix a race condition where schema reporting could lead to a delay at process shutdown. [PR #5222](apollographql/apollo-server#5222)
• apollo-server-core: Allow the Fetch API implementation to be overridden for the schema reporting and usage reporting plugins via a new fetcher option. [PR #5179](apollographql/apollo-server#5179)
• apollo-server-core: The server.executeOperation method (designed for testing) can now take its query as a DocumentNode (eg, a gql-tagged string) in addition to as a string. (This matches the behavior of the apollo-server-testing createTestClient function which is now deprecated.) We now recommend this method instead of apollo-server-testing in our docs. [Issue #4952](apollographql/apollo-server#4952)
• apollo-server-testing: Replace README with a deprecation notice explaining how to use server.executeOperation instead. [Issue #4952](apollographql/apollo-server#4952)

v2.24.1

• apollo-server-core: Fix a typo that could lead to TypeScript compilation when combined with a recent version of @types/node. (This bug had no runtime effect.) [PR #5149](apollographql/apollo-server#5149)

v2.24.0

• apollo-server-core: Apollo Studio usage reporting uses a more efficient format which sends fewer detailed traces to Apollo's server. This change should not have a major effect on the experience of using Apollo Studio. This also fixes a bug in all prior versions where all operations were reported to Studio as "uncached". [PR #4142](apollographql/apollo-server#4142)

v2.23.0

• apollo-server-core: Add optional argument to ApolloServer.executeOperation allowing the caller to manually specify an argument to the config function analogous to that provided by integration packages. [PR #4166](apollographql/apollo-server#4166) [Issue #2886](apollographql/apollo-server#2886)
• [email protected]: New BaseRedisCache class which takes an ioredis-compatible Redis client as an argument. The existing classes RedisCache and RedisClusterCache (which pass their arguments to ioredis constructors) are now implemented in terms of this class. This allows you to use any of the ioredis constructor forms rather than just the ones recognized by our classes. This also fixes a long-standing bug where the Redis cache implementations returned a number from delete(); it now returns a number, matching what the KeyValueCache interface and the TypeScript types expect. [PR #5034](apollographql/apollo-server#5034) [PR #5088](apollographql/apollo-server#5088) [Issue #4870](apollographql/apollo-server#4870) [Issue #5006](apollographql/apollo-server#5006)
• apollo-server-core: Fix type for formatResponse function. It never is called with a null argument, and is allowed to return null. [Issue #5009](apollographql/apollo-server#5009) [PR #5089](apollographql/apollo-server#5089)
• apollo-server-lambda: Fix regression in v2.21.2 where thrown errors were replaced by throwing the JS Error class itself. [PR #5085](apollographql/apollo-server#5085)
• apollo-server-core: If a client sends a variable of the wrong type, this is now reported as an error with an extensions.code of BAD_USER_INPUT rather than INTERNAL_SERVER_ERROR. [PR #5091](apollographql/apollo-server#5091) [Issue #3498](apollographql/apollo-server#3498)
• apollo-server-lambda: Explicitly support API Gateway payloadFormatVersion 2.0. Previously some codepaths did appropriate checks to partially support 2.0 and other codepaths could lead to errors like event.path.endsWith is not a function (especially since v2.21.1). Note that this changes the TypeScript typing of the onHealthCheck callback passed to createHandler to indicate that it can receive either type of event. If you are using TypeScript and care about having a precise typing for the argument to your onHealthCheck callback, you should determine which payload format you want to support and write new ApolloServer<APIGatewayProxyEvent>(...) or new ApolloServer<APIGatewayProxyEventV2>(...) (importing these types from aws-lambda), or differentiate between the two formats by checking to see if 'path' in event. [Issue #5084](apollographql/apollo-server#5084) [Issue #5016](apollographql/apollo-server#5016)

v2.22.2

• apollo-server-core: Fix a regression in v2.22.0 where combining apollo-server-core v2.22 with an older version of an integration package could lead to startup errors like called start() with surprising state invoking serverWillStart. The fix involves changing the semantics of the protected willStart method (which is left in only for backwards compatibility). [Issue #5065](apollographql/apollo-server#5065) [Issue #5066](apollographql/apollo-server#5066) [PR #5073](apollographql/apollo-server#5073)

v2.22.1

• apollo-server-core: Fix a regression in v2.22.0 where startup errors could be thrown as part of the GraphQL response instead of redacted in one edge case. [PR #5064](apollographql/apollo-server#5064)

v2.22.0

• Improve startup error handling by ensuring that your server has loaded its schema and executed its serverWillStart handlers successfully before starting an HTTP server. If you're using the apollo-server package, no code changes are necessary. If you're using an integration such as apollo-server-express that is not a "serverless framework", you can insert await server.start() between server = new ApolloServer() and server.applyMiddleware. (If you don't call server.start() yourself, your server will still work, but the previous behavior of starting a web server that may fail to load its schema still applies.) The serverless framework integrations (Lambda, Azure Functions, and Cloud Functions) do not support this functionality. While the protected method willStart still exists for backwards compatibility, you should replace calls to it with start or the new protected method ensureStarting. [PR #4981](apollographql/apollo-server#4981)

v2.21.2

... (truncated)

Commits

• a725306 Release
• 70a4312 Release
• f47c11d Release
• 42983b0 Release
• 19572d7 Release
• c8c0748 Release
• df92f39 docs: replace spectrum with community forum (#5228)
• 9e1bf7d Release
• f2349d0 Release
• 4e5f03e Release
• Additional commits viewable 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)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[danabrooks]

Should this PR have also changed the apollo-server version in the package.json file?

[calvincestari]

@danabrooks I don't believe so. This was a minor version bump going from 2.16.1 to 2.25.3. Package.json correctly has the version tag set to accept all minor version bumps within the 2.x.x major version release.

Are you possibly meaning why we're not bumping up to 3.x?

[danabrooks]

@calvincestari - No, nothing to do with 3.x, but in our forked version of apollo-ios that we've been using, the 2.16.1 version was popping up on a scan showing possible vulnerabilities in some of the indirect dependencies. The scanner was finding this version in the package.json file. I changed it in our fork by changing the package.json file, then updating the package-lock.json and committing both files. I was just thinking it might show up on some scans in the future. Thanks!

[calvincestari]

Hmm, the same problem exists with the Node-based documentation generation system. The vulnerability scanners are a bit overzealous in what they check, i.e.: not everything is production shipped code.

We do need to upgrade SimpleUploadServer to apollo-server 3.x though, or strip it out of this repo.

[danabrooks]

Understood - I'll keep an eye out for the changes.