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.
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 was inadvertently left in place as I didn't run into the usual
merge-conflict that I usually do on the CHANGELOG.md which is my natural
ergonomic which usually leads me to fixing it. Apologies!
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.
