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 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.
* 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.
The apollo-server-core package uses Node's built-in crypto module only to
create SHA-256 and -512 hashes.
When we're actually running in Node, the native crypto library is clearly
the best way to create these hashes, not least because we can assume it
will be available without having to bundle it first.
Outside of Node (such as in React Native apps), bundlers tend to fall back
on the crypto-browserify polyfill, which comprises more than a hundred
separate modules. Importing this polyfill at runtime (likely during
application startup) takes precious time and memory, even though almost
all of it is unused.
Since we only need to create SHA hashes, we can import the much smaller
sha.js library in non-Node environments, which happens to be what
crypto-browserify uses for SHA hashing, and is a widely used npm package
in its own right: https://www.npmjs.com/package/sha.js.
When getEngineServiceId does not return a truthy value, we can save memory
and startup time by avoiding importing apollo-engine-reporting, which
(among its other dependencies) imports the protobuf.js implementation.
This TEMPORARILY reverts commit 069110b353,
which was the result of the work done in #1971 by @rkorrelboom.
Unfortunately, we need to put this on ice while we wait for movement on a
package naming conflict. The dialog surrounding this is under way, as
I've explained in the PR:
https://github.com/apollographql/apollo-server/pull/1971#issuecomment-456817749
I'm excited to re-land this in an upcoming version, but there's no reason to
block the 2.4.0 release for it right now.
I will open a new PR with the work from #1971 in due time.
… version
This PR should hopefully correct some typing issues we are currently facing.
The problem:
- this package references v5.0.1 for @types/koa-bodyparser
- when we start our server that also uses koa-bodyparser for non-graphql routes, the type for koa.Request sets the "body" field to:
```
declare module "koa" {
interface Request {
body: {} | null | undefined;
rawBody: {} | null | undefined;
}
}
```
Which breaks our type defs for koa-bodyparser as we actually want "body" to be set to "any."
The v5.0.1 that was originally placed here is no longer "latest" and they have published a new v4 version that has the correct typing for koa-bodyparser (setting body to any). - https://www.npmjs.com/package/@types/koa-bodyparser
<!--
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:
* [ ] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [x] 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
Currently, the only place that we use `lodash` in the entire `apollo-server`
repository is to utilize the `sortBy` function in this signature generation.
Looking at the bundle stats, it appears that lodash represents 7.1% of the
`apollo-server` package. We're a server, so bundle size is generally less
of a concern, but it's still not to be ignored, particularly as we move into
worker environments. More pressingly though, since this package will be
utilized by the `apollo` CLI, we'll be shaving precious download time off
the invocation of `npx apollo` if we can get this down.
By switching to the modular package (but still depending on `@types/lodash`
for _just_ the `ListIteratee` type — which we only need in development — we
should be able to trim 55.4kB minified (19.1kB minified+gzip'd) off the
`apollo-server` build.
cc @trevor-scheer @jbaxleyiii @martijnwalraven
These AST visitors and transformations are more generally usable for other
purposes rather than just the Apollo Engine signature reporting and would
seem to belong in a module of their own.
Many of these signature calculation functions are now utilized in tools or
helpers which are not directly related to `apollo-server` functionality,
including various aspects of the `apollo` CLI which live within
`apollo-tooling`.
Currently, because of `apollo`'s dependency on `apollo-engine-reporting` for
this signature, this requires bringing in the entire dependency tree which
`apollo-server-core` relies on since `apollo-engine-reporting` depends on
`apollo-server-core`.
By moving this into this new `apollo-graphql` utility library, we're able to
trim that rather hefty dependency tree and drastically reduce the download
for running, say, `npx apollo`.
