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.
Hopefully this will act as reminder for the future. I've used `NODE` here
as a sort of `TODO` so other references in the codebase might be more easily
located.
Not only did removing this configuration reveal invalid JavaScript code, it
also fixes the source mapping for the coverage reports so that they report
the coverage details based on the original file rather than the `tsc`
compiled output (JavaScript).
Ref: c9375c405b (invalid top-level `return`)
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.
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`.
Rather than using platform-specific `find` and `rm`, we can leverage `git
clean` which will also work on Windows (in addition to making this command
more succinct).
This also runs in a fraction of the time than the `find` + `rm` approach.
This allows us to DRY up the `package.json` file and allows editors which
understand Prettier support to be aware of exactly which files are meant to
be covered, rather than including it within the CLI flags.
This is closer to removing `npm run testonly` which seems less intuitive
than it could be since, grammatically speaking, the `npm test` command
implies that it's only doing testing, not also recompilation.
Testing environments should already be configured to run `npm install`
followed by `npm test` (or the shorthands: `npm install-test` and `npm it`)
Therefore, if someone _wants_ the full recompilation running `npm it` again
will replicate the behavior previously accomplished by `npm test`. I find
this more intuitive since the `npm install` step was already doing the
complication (and necessary to produce a functioning Apollo Server monorepo).
And similarly, `npm test` now just runs the tests, rather than the more
expensive recompilation. This should become even more useful when we move
to a pattern where `tsc` incremental building is implemented.
Since we’ve moved to independent versioning the statement about every package within this repository being at the same version is no longer true. While we’ll need to improve our `CHANGELOG.md` story a bit to account for this, it’s best that we remove this statement to avoid confusing library consumers.
This PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| koa | devDependencies | pin | `^2.5.3` -> `2.5.3` | [source](https://renovatebot.com/gh/koajs/koa) |
📌 **Important**: Renovate will wait until you have merged this Pin PR before creating any *upgrade* PRs for the affected packages. Add the preset `:preserveSemverRanges` your config if you instead don't wish to pin dependencies.
---
### Renovate configuration
📅 **Schedule**: PR created on schedule "after 6pm every weekday,before 8am every weekday" in timezone America/Los_Angeles
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻️ **Rebasing**: Renovate will keep this PR updated whenever it falls behind the base branch.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://renovatebot.com/gh/renovatebot/config-help/issues) if that's undesired.
---
This PR has been generated by [Renovate Bot](https://renovatebot.com/gh/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#apollographql/apollo-server).
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.
* Incorrect sample codes
```const { ApolloServer } = require('apollo-server');```
should be
```const { ApolloServer, gql } = require('apollo-server');```
The functions in `mocks` would be used when no resolver in `resolvers` is specified only when `mockEntireSchema: false`.
* Update mocking.md
Change the documentation to be correct, indicating that the mocks overwrite the resolvers
* Allow an optional function to resolve the rootValue
Passes the parsed DocumentNode AST to determine the root value,
useful when providing a different rootValue for query vs mutation
* Add API docs for rootValue
On version 3.1.1 there is an error ( `Error: Invalid schema passed` ) when wrapping the `linkTypeDefs` in `gql`. Passing the plain string the example works.
* Specify explicit `cursorShape` to avoid missing cursor in GraphQL Playground.
This solves a problem with the text cursor caret not being visible in the
operation input box within GraphQL Playground by explicitly setting a
GraphQL Playground configuration option called `cursorShape` to `line`.
All credit for the actual solution goes to @lpellegr for their discovery in
https://github.com/prisma/graphql-playground/issues/790#issuecomment-409221277
* Update CHANGELOG.md
<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>
The `generateClientInfo` API, used to set client identification attributes
within traces, is an experimental API and is subject to removal or change in
a future (major) Apollo Server release.
Ref: #1631
* Updated request handler to handle null or undefined req.path
* Added test for GCF handling request.path being null
* Updated Changelog
* Add note about checking for null path
* Provide ability to specify client info in traces
Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.
* Use extensions and context in createClientInfo
* Remove support for clientAddress
The frontend will not support it in the near future
* create -> generate and make default generator
createClientInfo -> generateClientInfo
* Clarify default values
