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.
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
* Initial basic Micro integration
* Wire up health check capabilities
* Add playground support; Refactoring
* Add custom path support
* Add file upload support
* Add subscription support
* Documentation and formatting updates
* Wire up tests
* Add Node 10 workaround for file upload testing
* Code review changes (docs, naming, formatting)
* Adjust exports to line up with other integrations
* micro: add graphql to npm install and lines to highlight in docs
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.
