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.
Renovate v12 introduces a default of `pinVersions=false` and removes the hardcoded `peerDependencies.pinVersions=false` setting. This repository's root level `pinVersions=true` therefore then trickles down to `peerDependencies` as well. This PR updates Renovate config to use a preset that pins everything except `peerDependencies`.
The default syntax highlighting provided by Hexo uses highlight.js. While
there are a number of great syntax highlights provided by highlight.js, some of
the more important ones to the Apollo project: `graphql`, `typescript`, and
`jsx` are notably missing.
This uses the `hexo-prism-plus` plugin for Hexo, along with some upstream
configuration to `apollo-hexo-config`[0] and `meteor-theme-hexo` (previously
named `hexo-theme-meteor`)[1]. See refs for more information!
[0] https://github.com/apollographql/apollo-hexo-config/commit/547107b0
[1] https://github.com/meteor/meteor-theme-hexo/pull/61
As determined in
https://github.com/renovateapp/config-help/issues/23#issuecomment-377202632,
it seems that it's not possible to have this sort of inherited
configuration. It's possible that when I first introduced this behavior
that this behavior was on its way out (and the breaking change in Renovate
v11 on its way in).
Luckily, Renovate's shared configuration option still allows this to be
relatively painless and our `apollo-docs` shared configuration[0] does most
of the heavy lifting here so there won't be too much Renovate toe-stepping.
If this works well in the `apollo-server` repository, I'll transplant this
change to the other docs repositories[1].
[0] https://github.com/apollographql/renovate-config-apollo-docs
[1] https://github.com/meteor/hexo-theme-meteor