First, the getting started example was incorrect and instructed users to
install the wrong package.
Furthermore, each integration example was duplicated on its individual
package `README.md` and the verbosity of this `README.md` (which is for the
entire monorepo) makes it unclear where to start.
This change points those who desire the integration approach to the specific
page which has more information about those integrations (and mostly the
same content in terms of examples which are listed here, albeit with subtle
variations.)
While it used to be required to pass the `--save` flag in order to actually
write the dependency to the project's `package.json` file, this is no longer
the case in recent versions of npm.
Previously, in order to only load dependencies which only work on Node.js
and fail in non-Node.js environments, we introduced a check which did a
string-comparison of `process.release.name` to see if it is was `node`.
This was first introduced in 9c563fae50 as
part of #2054, but has gone on to be useful for other purposes as well.
Some Node.js forks such as NodeSource's N|Solid, which is a fork of Node.js
which follows-up each Node.js release with a custom build that includes
additional native addons but is otherwise the same, override this value with
their own name. This means that N|Source returns `nsolid`, despite the fact
that it is almost entirely the same as Node.js.
Luckily, N|Solid leaves the base version of its Node.js in
`process.versions.node` (and additionally adds its own
`process.versions.nsolid`). By relaxing the string comparison on
`process.release.name`, we should still be able to accurately detect the
environment we want - which is "Close enough to Node.js!".
Fixes https://github.com/apollographql/apollo-server/issues/2356
* Add AS constructor with context usage to tests
* fix(typing): Context template type should be 'object' and not 'any'
```context?: ContextFunction<ExpressContext, any> | Context<any>;```
is
```context?: ContextFunction<ExpressContext, any> | any;```
which is
```context?: any;```
https://github.com/Microsoft/TypeScript/issues/18568
Since the ContextFunction<...> part is ignored, no type hinting will be provided when a function is passed to `context`. We don't really mean `any`, we mean an object with any shape, so we should use `object` instead
* fix(typing): type ContextFunction params separately from resulting context object
* Update changelog
* rename: ContextContent -> ProducedContext
* Type formatErrors function to specify that it accepts and returns ApolloError
* Update changelog
* type(formatErrors): accept GraphQLError, return GraphQLFormattedError
* update changelog
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.
