This should hopefully make it easier to quickly identify failing tests
within the CircleCI interface since CircleCI will be able to
programmatically consume the test results.
This adds the `--coverage` flag to the `test:ci` (Jest) script, in addition to
adding two new commands (mirroring the pattern used in Apollo Client's
repository): `npm run coverage` and `npm run coverage:upload`.
CircleCI has been configured with the appropriate `CODECOV_TOKEN`.
I'm reverting apollographql/apollo-server#1698 not because it's been problematic in any way, but because I'd like to give it a bit more thought and don't want this to accidentally get cut into a release prior to that consideration.
More specifically: The `graphql-tools` update on its own shouldn't really cause any problems, but the [4.x version of `graphql-tools`](https://github.com/apollographql/graphql-tools/releases/tag/4.0.0) is intended to support and enable the latest `graphql@14` which contains [breaking changes](https://github.com/graphql/graphql-js/releases/tag/v14.0.0).
I believe most of those breaking changes would be show-stoppers and the failures would surface immediately (meaning that servers would completely fail to start, rather than being a surprise in other, more delayed scenarios), but it's still worth pausing and carefully considering versioning to avoid any surprises.
That said, the 14.x version of `graphql` has been an acceptable range in the `peerDependencies` of `apollo-server-*` since before its final release came out, and I don't believe we've caught wind of anything that a major version bump would have prevented or made more clear. In the end, `graphql` is a peer dependency and any problems should only surface if consumers also update their `graphql` dependency — a clear major version bump, which deserves review by the upgrader — so perhaps we can avoid bumping the major version after all?
Input welcomed, but again, merging this now to give this a bit more thought first.
cc @hwillson
`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.
<p>This Pull Request updates devDependency <code>yup</code> (<a href="https://renovatebot.com/gh/jquense/yup">source</a>) from <code>v0.26.5</code> to <code>v0.26.6</code></p>
<p><strong>Note</strong>: This PR was created on a configured schedule ("after 6pm every weekday,before 8am every weekday" in timezone <code>America/Los_Angeles</code>) and will not receive updates outside those times.</p>
<p><details><br />
<summary>Release Notes</summary></p>
<h3 id="v0266httpsgithubcomjquenseyupcomparev0265v0266"><a href="https://renovatebot.com/gh/jquense/yup/compare/v0.26.5…v0.26.6"><code>v0.26.6</code></a></h3>
<p><a href="https://renovatebot.com/gh/jquense/yup/compare/v0.26.5…v0.26.6">Compare Source</a></p>
<hr />
<p></details></p>
<hr />
<p>This PR has been generated by <a href="https://renovatebot.com">Renovate Bot</a>.</p>
* 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`.
