This commit again looks quite complicated, but's merely an over-complication
inflicted by Prettification. Disabling whitespace differences when viewing
this commit, the functional change here is that we no longer skip many file
upload tests when the (semver) major segment of `process.version` is `10`.
I couldn't be happier to get rid of this exception for file upload tests on
Node.js 10, which was an unfortunate reality of the non-updated
`graphql-upload` module world we previously lived in.
Thanks, @jaydenseric, for the newfound (to us!) Node.js upload support!
This commit looks way more complicated than it really is thanks to Prettier
trying to be helpful.
All I've done is add `NODE_MAJOR_VERSION === 6` as a version NOT to test
uploads for, in an effort to fix the failing tests (failing appropriately
since Node.js 6 with file uploads throws an error right now and cannot run
uploads anymore.).
I hope to actually remove this limitation, but I'm going to iterate on it
first. This also just switches to a `NODE_MAJOR_VERSION` constant from the
`apollo-server-integration-testsuite` rather than using the GTE function on
the same input since...math.
Due to changes in the third-party `graphql-upload` package which Apollo
Server utilizes to implement out-of-the-box file upload functionality, we
must drop support for file uploads in versions of the Node.js engine prior
to v8.5.0. Since file uploads are supported by default in Apollo Server 2.x,
and there is an explicit dependency on `graphql-upload`, we must
prevent users who are affected by this mid-major-release deprecation by
being surprised by the sudden lack of upload support.
By `throw`-ing an error at server startup for affected users, we certainly
are breaking a semantic versioning agreement for these users, however with a
relatively simple ergonomic (setting `uploads: false`) we allow those users
who are NOT utilizing file uploads (as we believe is the case with a
majority) to continue using their version of Node.js until it reaches the
end of its supported lifetime (as dictated by its Long Term Support
agreement with the Node.js Foundation). If we did not `throw` the error at
server start-up, those affected may not notice since they may update and start
their updated server without noticing the impending chance of failure when
someone tries updating!
Apollo Server 2.x has attempted to maintain full compatibility with versions
of Node.js which are still under Long Term Support agreements with the
Node.js Foundation. While this continues to mostly be true, file uploads
are an exception which we've now had to make.
Third-party open-source projects must absolutely do what's best for their
project. From an architecture standpoint, I suspect that we (the designers
behind Apollo Server) are mostly to blame for this. Namely, it's unfortunate
that we had made such an incredibly coupled integration with a third-party
package that we restricted our users from incrementally adopting the
changes (and new/improved functionality) of, in this particular case,
the `graphql-upload` package. I hope we can take better care with decisions
like this in the future!
Lastly, this commit also adds documentation to help those affected.
With any luck, we will no longer necessitate our fork which removed the
`graphql-config` dependency thanks to the work done in:
https://github.com/prisma/graphql-playground/pull/874🎉
Most notably though, this fixes a documentation scrolling problem with
Safari.
This mostly reverts fd34771841 along with a
number of slight adjustments to avoid other typing luxuries which were
introduced with TypeScript 3.x.
While the generic `ServerOptionFunction` types and `HandlerArguments`
generic rest argument type were certainly welcome additions to the codebase,
they present a backwards compatibility problem for consumers of Apollo
Server who have not yet made the jump to TypeScript 3.x.
With any luck, when we bump the major version of Apollo Server to 3.x, and
in accordance with semantic versioning, we'll be in the position to
straight-up revert this commit.
By avoiding this pattern, we can maintain better typing for users of
TypeScript 2.8, which didn't maintain typings when passing through
`Function.prototype.bind` calls.
Also, personally, this just appears to be more readable.
This commit follows-up on #1795, which introduced the new request pipeline, and
implements the triggers for its new life-cycle hooks within the various
integration packages. Previously, the only implementation was within the
`apollo-server` package and didn't get triggered for those invoking the
`applyMiddleware` method on integrations (e.g. `apollo-server-express`,
`...-hapi` and `...-koa`).
While in an ideal world, ALL existing `applyMiddleware` functions would be
marked as `async` functions and allow us to `await ApolloServer#willStart`,
in practice the only `applyMiddleware` which is currently `async` is the one
within the Hapi implementation. Therefore, we'll instead kick off the
`willStart` lifecycle hook as soon as `applyMiddleware` is started, return
as quickly as we have before and then (essentially) yield the completion of
Apollo Server's `willStart` prior to serving the first request — thus
ensuring the completion of server-startup activities.
Similarly, we'll do the same for `createHandler` methods on integrations
which don't utilize Node.js server frameworks but don't have `async`
handlers (e.g. AWS, Lambda, etc.).
Since activating the EngineReportingAgent is now dependent on being able to extract an engineServiceId from the API key, tests need to specify one that follows the expected structure.
We can't use `apollo-server-env` as a project reference because that requires `composite: true`, and that implies `declaration: true`, which doesn't work for `apollo-server-env` because we need to write our own declaration files for re-exported imports.
This commit also removes `apollo-engine-reporting-protobuf` as a reference, which errored out because it doesn't actually contain any TypeScript code.
