* AER: Remove encodedTraces to prevent duplicates
When there are multiple instances of apollo-engine-reporting, the
`Trace.encode` method gets wrapped each time to add the
`encodedTraces`. In order to prevent them from being added to the
protobuf multiple times, we remove the encodedTraces after adding them
once
* Add changelog
* Move incremental Trace encoding to a-e-r-protobuf
To enable incrmental compilation of traces, we add a patch to the
Trace.encode method generated by protobujs to accept and store encoded
traces. Occassionally with multiple instances of apollo-engine-reporting
that share the same version of the protobuf, the wrapper method gets
applied more than once. In order to ensure that the wrapper only gets
applied once, we patch the Trace.encode method inside of
apollo-engine-protobuf.
tsc hangs on the processing the generated protobuf.js files, so the
tsconfig.json ignores the generated protobuf file. In order for the
typescript index.ts file to compile the generated protobuf.js file is
output to the src folder. To ensure the protobuf files are available to
the production build, `npm run compile` copies the protobuf file
manually from src to dist.
* Reexport protobuf import after modification
`export * from './protobuf'` exports the unmodified reference
* Update comment on Trace.encode to point at a-e-r-p
The override now occurs inside of apollo-engine-reporting-protobuf due
to the case of having multiple reporting challenges, so we need to
update the comments to help indicate that
* Remove typescript build step
In order to simplify the generation of this library, we move the change
the index.ts file into index.js and remove the typescript build step.
Since the type safety is created by the protobufjs generation, this
seems acceptable. In general this portion of the code should remain
relatively stable, so generating and copying the code with `prepare`
remains reasonable.
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.
BUGFIX: the playground page is currently being served without a content type
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
TODO:
* [x] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [ ] Make sure all of the significant new logic is covered by tests
* [x] Rebase your changes on master so that they can be merged easily
* [x] Make sure all tests and linter rules pass
Now that there are specific versions of Node.js which don't support file
uploads (namely, <= 8.5.0) we need to explicitly disable uploads on those
versions, similar to how those users must opt-in to that behavior by setting
`uploads: false` in their Apollo Server constructor options.
This effectively accomplishes exactly that, but only when necessary.
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 PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| @​types/hapi | devDependencies | minor | `17.6.4` -> `17.8.0` | [source](https://renovatebot.com/gh/DefinitelyTyped/DefinitelyTyped) |
---
### Renovate configuration
📅 **Schedule**: "after 6pm every weekday,before 5am every weekday" in timezone America/Los_Angeles.
🚦 **Automerge**: Enabled.
♻️ **Rebasing**: Whenever PR is stale, or if you modify the PR title to begin with "`rebase!`".
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
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).
Follow-up on the update to `graphql-playground-html` in previous release by
also bumping the minor version of the `graphql-playground-react` dependency
to `1.7.10` — which is the version requested from the from the CDN bundle by
`graphql-playground-html`.
Ref: https://github.com/apollographql/apollo-server/pull/2037
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 was something I just happened to spot, though further investigation is
likely necessary to determine if other similar cases can be discovered.
This fixes this test to `expect` the number of additional `expectations we
have expressed for it: 2.
Testing errors in `catch`es of `Promise` chains necessitates the use of
`expect.assertions(n)` where `n` is the number of assertions declared in
that particular test.
Without this `expect`ation clearly defined, a resolved `Promise` will not
result in the assertion being tested. For example, if the `query` passed to
this test was a query against a type in the schema (i.e. `query: 'foo'` was
replaced with `query: { query: '{ testString }' }`) the desired error would
not be produced, but the test would still pass. I'm not saying that's
likely, but there's certainly the possibility that (given fault code)
something else in the plumbing could cause that Promise to resolve.
Ref: https://jestjs.io/docs/en/tutorial-async#error-handling
This is mandated by `lru-cache` v5 and surfaced the CircleCI failures on #2004:
https://circleci.com/gh/apollographql/apollo-server/22537
Luckily, this is a private implementation detail of Apollo Server's
`InMemoryLRUCache` so no additional changes should be necessary and we should
be able to update to `lru-cache` 5.0.0 in a semver minor respectful way.
