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.
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.
Some changes are easier to mentally consume before they've been prettier'd.
While I'll certainly allow Prettier to do what it wants to do, I've confined
it's changes to this commit for easier reviewability.
Note to the reviewer: this commit is exactly the result of running the
`npm run lint-fix` command on a clean Git working tree.
Ref: c9375c405b
The techniques previously used to skip particular tests for particular
Node.js versions (for example, file uploads, Hapi, etc.) were problematic in
a couple ways:
1. `return`-ing outside a function (say, at the top level of a module) is
not valid ECMAScript. While it works in this current state, it only works
because of Babel's wrapping scope. As we move toward less and less
transpiled modules, this would become problematic anyway, but it's a
short-term blocker for me since I intend on dropping the `skipBabel` option
we currently pass to` `ts-jest` in its current (`package.json`)
configuration. (My editor also dislikes top-level `return`, expectedly.)
2. By `return`-ing from a test which we wish to skip conditionally, we avoid
the awareness which is provided by Jest (automatically) when using its
built-in `.skip` helpers. By switching to technique I've employed here,
we're able to see `<num> skipped` in Jest's output and (rightfully) be able
to question why something is being skipped.
By using the `atLeastMajorNodeVersion` helper, we'll also be able to more
easily find where this pattern is used in test-cases, to more easily
re-evaluate their use-cases when we add support newer Node.js versions.
`esModuleInterop` was enabled in
e4164c8892
to help with importing from packages that use default exports.
Those changes were reverted in
https://github.com/apollographql/apollo-server/pull/1210
to work around a few reported issues. Those issues are no longer
relevant, so this commit re-enables `esModuleInterop`, and
updates all default imports to use the more common (standard)
import syntax.
* Switch to a fork of `apollo-upload-server` to fix missing `core-js` dependency.
As reported in https://github.com/apollographql/apollo-server/issues/1542,
the `apollo-upload-server` package (v5.0.0, which `apollo-server` relies on)
is no longer able to provide a `core-js` package because of change that was
outside of its control in a Babel release.
The problem is resolved in newer versions of `apollo-upload-server`,
however, regrettably, the newer versions of that package (notably, v6 and
v7) drop support for Node.js 6 — one of two versions of Node.js that are
currently under the terms of the Node.js Foundation's Long-Term-Support
(LTS) agreements.
Since Apollo Server aims to support versions of Node.js which are under LTS
(and will drop support for Node.js 6 in April 2019, per Node.js' schedule)
the current, immediate solution is to fork the `apollo-upload-server`
package as `@apollographql/apollo-upload-server`.
With the inclusion of
https://github.com/apollographql/apollo-upload-server/pull/1, we are able to
keep supporting Node.js 6. Without this change, every new installation
of `apollo-server`, which doesn't have a `package-lock.json` preventing
transitive dependency updates - specifically, the updates to
`@babel/runtime` versions newer than `-beta.56` - is broken.
* [squash] Update to `@apollographql/apollo-upload-server@5.0.2`.
* [squash] Update to `@apollographql/apollo-upload-server@5.0.3`.
* Add a wider diversity of `gui` options
Although I know we want to remain less tied to the GraphQL Playground
GUI options, we definitely want to support a wider variety of options to
be passed in. This adds support for specifying partial options either
statically or dynamically for the gui, which can be extended to allow
for a wider array of guis than only GraphQL playground.
* Add boolean option and configuration for tabs
* move gui setting into ApolloServer Constructor
* document playground configuration in the constructor
* update playground types and fixed micro + koa integrations
* change gui to playground
* docs: change gui to playground
* fix logic for playground creation
* koa integration
* use koa-bodyparser v3 for node 6 support
* use middlewareFromPath instead of koa-router
* use async/await in koa fileUploadMiddleware
Previously, we were planning to offer two kinds of APIs in "Apollo Server 2":
middleware functions just like in 1.0, and the new ApolloServer class. We have
not yet implemented ApolloServer for all of our supported web frameworks, so
this meant that the 2.0 version of modules such as apollo-server-koa (which does
not yet have an ApolloServer class) offered very little benefits over
apollo-server-koa@1.0 (as most of the benefits of 2.0 come from ApolloServer).
This is confusing. We are going to improve the current registerServer API so
that there's no real benefit to using a separately-exported middleware directly
rather than creating an ApolloServer and applying it to your web framework. So
the AS 2.0 API will just be ApolloServer. This means it doesn't make sense for
us to publish 2.x versions of the packages that don't yet support this API.
So this commit removes support for the following web frameworks: Adonis, Azure
Functions, Koa, Lambda, Micro, and Restify. (We leave in place Express, Hapi,
and Cloudflare workers.)
This isn't because we don't like these frameworks and don't want them to work
with Apollo Server 2.0! We would love to see each package resurrected and an
ApolloServer implementation built, either during this current 2.x beta phase or
after the official 2.0 release. Deleting these packages for now makes it more
clear which frameworks support 2.0 and which don't, rather than existing in a
state where apollo-server-express@2 has ApolloServer and apollo-server-koa@2
does not.
As originally reported in [0], this should make debugging performance issues
easier, since the name of the function will be properly displayed/shown in
flame-graphs.
[0]: https://github.com/apollographql/apollo-server/pull/827
