This uses `hexo-versioned-netlify-redirects`[0], a package I wrote just for
this purpose (on Meteor) a few months back.
With any luck, this will do the trick for Apollo too.
[0]: https://github.com/meteor/hexo-versioned-netlify-redirects
This should enable the dropdown box in the sidebar of the documentation.
Currently, that sidebar will be a terrible color, since it has never
appeared on Apollo documentation before and nobody has ever defined style on
it. That'll have to be fixed in the theme itself[0].
[0]: https://github.com/meteor/meteor-theme-hexo
npm 6 deprecates support for Node.js 4, which is still LTS until the end of
the week.
It's probably best to take a moment and ensure that npm@6 is actually
working as we desire too, so this is just to make sure that we don't end up
with a bunch of PRs that need to be re-based/re-tested, which seems to
already be happening.
Apollo Persisted Queries is a standard for sending queries as short hashes
instead of full strings, designed to work well with GET requests. It is
implemented by servers including the Apollo Engine Proxy, and by the
apollo-link-persisted-query client.
A common configuration is to set up persisted queries on production servers but
not in development. It is still convenient to leave apollo-link-persisted-query
always on, though. While apollo-link-persisted-query can detect that servers
don't support PQs, it works better if the server actually says it doesn't
support the PQ, instead of trying to process a request without a query and
potentially printing a confusing stack trace. This commit makes apollo-server
directly return PersistedQueryNotSupported instead of allowing confusing stack
traces to occur.
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.
