This will allow `/deployment` to be the "basics" page for deployment and
avoid re-using the term "Best Practices" in a section that isn't inside the
"best practices" portion of the guide.
This should avoid needing to include `[skip ci]` on every commit on branches
which are committed to docs, though will still provide us one "master"
branch run of tests when the PR lands.
We may want to remove this (maybe? longer-term), but this seems like a
short-term "win" on this branch for the time being.
cc: @jbaxleyiii @evans
The express-graphql reference implementation [provides a check]
(2e27a73358/src/index.js (L201-L208))
to protect against cases where a GET request is made that does not
have a `query` parameter where the GraphQL query would be present.
Without this guard, graphql-js's `parse` will return `undefined`
for the `DocumentNode` since it has no document to read. Subsequently
passing this to `isQueryOperation` results in a `TypeError`, because
we are providing `undefined` where `getOperationAst` [expects to get
a DocumentNode](5fe39262a3/src/utilities/getOperationAST.js (L19)).
A new test file is added for `runHttpQuery`, as one previously did
not seem to exist.
This change was introduced by the changes in apollographql/apollo-server#802
but first showed its head in apollographql/apollo-server#908. The reason that
violations in new type definitions aren't being found until subsequent PRs
isn't entirely clear but, ignoring that CI-related annoyance, the problem
itself here is very concrete.
It traces back to a major version update to `@types/mocha` via [Exhibit A],
which makes it unacceptable to return anything besides a `Promise` or
_nothing_ from a Mocha test factory.
I agree with this change in principle, since generally speaking there can be
multiple `expect` statements in each test and there is no particular reason
that the last one's value should be getting returned as Mocha doesn't do
anything functional with it.
More than anything, this seems like an artifact of an ESLint rule which
mandated that the last value in a function be returned, à la CoffeeScript or
other languages.
This will fix the failing tests on apollographql/apollo-server#908 and other
PRs currently in-flight.
Exhibit A: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/24301
As originally reported in [0], this should make debugging performance issues
easier, since the name of the function will be properly displayed/shown in
flame-graphs.
[0]: https://github.com/apollographql/apollo-server/pull/827
It appears that the intention of including `npm-check-updates` in this
repository was to provide an easy way to update dependent packages from the
console. This was originally introduced in [Ref 0].
Unfortunately, the `npm-check-updates` package has an explicit dependency on
`npm@3`, which means that it includes the entire `npm` in its
`node_modules`.
I originally observed this when analyzing the test failures in [Ref 1] and
[Ref 2] which indicated (in its npm error) that the npm version was v3.10.10.
The explanation for this is relatively straight-forward: Older versions of
npm uses an nested tree of `node_modules` directories while newer versions
hoist `node_modules` (i.e. flatten) to the highest location possible and
only nesting dependencies to meet conflicting version constraints.
Unfortunately, that means that once `npm@3` was installed by the newer
`npm@5` as a dependency of `npm-check-updates`, it was hoisted to the
top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which
directly call `npm` commands on the nested packages, as is done on this
monorepo (with, for example the `postinstall` script which runs `npm run
compile` in each of the server middleware packages). :face_palm:
Overall, this package doesn't seem to provide enough value for us to
continue to include it, especially since we have Renovate - coupled with the
same information being available from `npm outdated` and `npm update`
commands. I'm not sure why we would want to install newer versions than our
"package.json" allows.
Futhermore, looking at the issue tracker on `npm-check-updates`, I'm
assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on
this repository recently and _possibly_ even a bizarrely corrupted npm cache
I encountered recently (though admittedly, that could be a stretch).
See also: [Ref 4].
[Ref 0]: https://github.com/apollographql/apollo-server/commit/d7ca07f7
[Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915
[Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7
[Ref 3]: https://github.com/tjunnone/npm-check-updates/issues/420
[Ref 4]: https://github.com/tjunnone/npm-check-updates/issues/423
* Added fixes to apolloAzureFunctions.js and sample functions for the GraphQL API and GraphiQL
* Added issue and pr details to changelog
* Maintain use of `context.done()`, but use `isRaw` instead.
Per the Azure documentation regarding the response object available at:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#response-object
* Switch Azure example to use CommonJS rather than native ESM exports.
