As we're moving the community from Slack to Spectrum, its time to update
these shields from our project README files (which show on npm and in
GitHub) to reflect the new home for conversation.
If you haven't already joined the new Apollo community on Spectrum.chat,
visit https://spectrum.chat/apollo/ to join the discussion!
For more details on the move, checkout the Apollo blog post by @hwillson:
https://blog.apollographql.com/goodbye-slack-hello-spectrum-8fa6b979645b
This is necessary after the changes in 0f75909e35
and https://github.com/apollographql/apollo-server/pull/2344, as the
`AddressInfo` type didn't become available until a future version of
`@types/node`.
Regardless, it seems to me that this should be inferred without any problem
and we don't actually rely on the `AddressInfo` type, and instead are only
looking for an interface which has `port`, `address` and `family`, as the
inferred return value from `http.Server.prototype.address()` does.
While there are newer types available for newer Node.js APIs, the `8.x` range still gets most of the important updates via back-ports on the `DefinitelyTyped` repository. I believe it'll be safer to limit the types to the version which we intend on developing for most directly, which is Node.js 8. Node.js 10 has newer APIs but until we can drop Node.js 8 support (which is not at all anytime soon), we should try to stick to the `8.x` API types.
We will drop Node.js 6 support in the next major version of Apollo Server since it will end it's "Long-Term Support" coverage [in April 2019](https://github.com/nodejs/LTS/).
Hopefully this will auto-close #2302. 😉
I get the following error when using the apollo-server-core with typescript (3.2.4) :
```
node_modules/apollo-server-core/dist/types.d.ts:4:8 - error TS1192: Module '"/node_modules/@types/ws/index"' has no default export.
import WebSocket from 'ws';
```
The change fixes this error!
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
While it would be perfectly fine to use `import *` in this particular case,
we've moved away from the star-import pattern in this repository, instead
preferring the `esModuleInterop` compiler option which seems to be the
direction that TypeScript is moving as it's now the default with `tsc --init`.
TypeScript clearly lost its battle with `import *` which many consider to
have been an incorrect direction in the first place. Some build tools won't
work with star imports, and using them can make some optimizations more
difficult. By avoiding this pattern here, hopefully we'll avoid moving back
in that direction inadvertently.
Here's a read I found at one point which roughly explains:
https://itnext.io/great-import-schism-typescript-confusion-around-imports-explained-d512fc6769c2
We've generally moved away from the star-import pattern which TypeScript
also no longer generates with its default `tsc --init` configuration, so it
seems to make sense to keep picking exactly what we want since this pattern
is no longer forced upon us by TypeScript.
* typing: context function could return value synchronously
* Create ApolloServerExpressConfig type that has req and res in context
* Have apollo-server-express's constructor also use the express-specific config
* Update changelog
These missing configurations, which weren't identified in the original
implementation of `apollo-server-azure-functions` in #1926, are responsible
for the failures which have surfaced in the #2228, which updates Jest to v24.x.
When debugging the fix in b84770cdec, I
removed the `package-lock.json`, ran `npm install`, then individually
reviewed the fixes to better understand what happened.
I noted a few other differences in the `package-lock.json`, mostly due to
changes in `fsevents` (which internally switched to `bundledDependencies`),
and changes in `@apollographql/apollo-tools`.
I've reviewed these as well, and they all look reasonable, but wanted to put
them in a different commit for later bisecting purposes (hopefully a purpose
I won't have!).
Without this fix to `package-lock.json`, which it's not immediately clear to
me what was wrong (possibly a transitive error) there were type errors
manifesting on the `master` branch.
* test: ensure "total duration" > "duration of resolvers"
Add test for https://github.com/apollographql/apollo-server/pull/2298
* Update tracing duration test to be more comprehensive
Previously we were only guaranteeing that individual resolvers didn't have a duration longer than the total duration. The updated test guarantees that the duration (from when the first resolver started to when the last resolver ended) should be less than total duration
* Add another resolver to tracing test
* Prefer `const` over `let` for variables which aren't mutated.
