* Remove `willStart` from `apollo-server`, already called via `...-express`.
When the request pipeline was initially introduced, the integrations
had yet to be updated to call the new life-cycle events. Now, the
integrations have all caught up, but `apollo-server` is still calling
`willStart`, despite the fact that its dependency which provides the actual
server implementation — `apollo-server-express` – is _also_ calling it,
resulting in double invocation of this event.
I suspect some follow-up work should guard against this possibility, but for
now this should remove the duplication.
* Update CHANGELOG.md for #2239.
Ref: https://github.com/apollographql/apollo-server/pull/2239
I get the following error when using the apollo-server-core with typescript (3.2.4) :
node_modules/apollo-server-core/dist/types.d.ts:4:8 - error TS1192: Module '"/node_modules/@types/ws/index"' has no default export.
import WebSocket from 'ws';
The change fixes this error!
This is consistent with the old engineproxy interpretation of cache hints. We
special-case scalar fields to inherit their parent field's hints for
simplicity (so you don't have to hint every scalar field in a hinted object),
but when the parent field is non-root that inherited hint gets defaultMaxAge
applied to it. When the parent field is the root, that inherited hint doesn't
get defaultMaxAge applied because we don't run willResolveField for the root
query.
Includes a CHANGELOG update for #2197.
Since we already write to the persisted query cache asynchronously (and
intentionally do not await the Promise) this won't have any affect on the
current behavior of when the persisted query cache is written to in the
event of an executable request, but if an operation comes in and doesn't
parse or validate, we'll avoid wasting cache space on an operation that will
never execute.
Additionally, in a similar light, if a plugin throws an error which stops
execution, we can avoid the side-effect of writing to the persisted query
cache.
In terms of the APQ behavior, while this could cause additional round-trips
for a client which repeatedly sends an invalid operation, that operation is
never going to successfully finish anyway. While developer tooling will
help avoid this problem in the first place, this refusal to store an invalid
operation in the APQ cache could actually help diagnose a failure since the
full operation (rather than just the SHA256 of that document) will appear
in the browser's dev-tools on the retry.
If we're looking to spare parsing and validating documents which we know are
going to fail, I think that's going to be a better use of the (new)
`documentStore` cache (#2111), since its in-memory and can accommodate a
more complex data structure which includes the validation errors from the
previous attempt which will, of course, be the same when validating the same
operation against the same schema again. As the PR that introduced that
feature shows, sparing those additional parses and validations (cached APQ
documents still needs to be parsed and validated, currently) will provide a
more successful performance win overall.
Ref: https://github.com/apollographql/apollo-server/pull/2111
This PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| prettier | devDependencies | minor | `1.15.3` -> `1.16.1` | [homepage](https://prettier.io), [source](https://togithub.com/prettier/prettier) |
---
### Release Notes
<details>
<summary>prettier/prettier</summary>
### [`v1.16.1`](https://togithub.com/prettier/prettier/blob/master/CHANGELOG.md#​1161)
[Compare Source](https://togithub.com/prettier/prettier/compare/1.16.0...1.16.1)
[diff](https://togithub.com/prettier/prettier/compare/1.16.0...1.16.1)
- JavaScript: Do not format functions with arguments as react hooks ([#​5778] by [@​SimenB])
The formatting added in Prettier 1.16 would format any function receiving an
arrow function and an array literal to match React Hook's documentation.
Prettier will now format this the same as before that change if the arrow
function receives any arguments.
<!-- prettier-ignore -->
```js
// Input
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
(allColors, color) => {
return allColors.concat(color);
},
[]
);
// Output (Prettier 1.16.0)
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce((
allColors,
color
) => {
return allColors.concat(color);
}, []);
// Output (Prettier 1.16.1)
["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
(allColors, color) => {
return allColors.concat(color);
},
[]
);
```
- JavaScript: Add necessary parentheses for decorators ([#​5785] by [@​ikatyang])
Parentheses for decorators with nested call expressions are optional for legacy decorators
but they're required for decorators in the current [proposal](https://tc39.github.io/proposal-decorators/#sec-syntax).
<!-- prettier-ignore -->
```js
// Input
class X {
@​(computed().volatile())
prop
}
// Output (Prettier 1.16.0)
class X {
@​computed().volatile()
prop
}
// Output (Prettier 1.16.1)
class X {
@​(computed().volatile())
prop
}
```
- TypeScript: Stable parentheses for function type in the return type of arrow function ([#​5790] by [@​ikatyang])
There's a regression introduced in 1.16 that
parentheses for function type in the return type of arrow function were kept adding/removing.
Their parentheses are always printed now.
<!-- prettier-ignore -->
```ts
// Input
const foo = (): (() => void) => (): void => null;
const bar = (): () => void => (): void => null;
// First Output (Prettier 1.16.0)
const foo = (): () => void => (): void => null;
const bar = (): (() => void) => (): void => null;
// Second Output (Prettier 1.16.0)
const foo = (): (() => void) => (): void => null;
const bar = (): () => void => (): void => null;
// Output (Prettier 1.16.1)
const foo = (): (() => void) => (): void => null;
const bar = (): (() => void) => (): void => null;
```
- MDX: Correctly recognize inline JSX ([#​5783] by [@​ikatyang])
Previously, some inline JSXs are wrongly recognized as block HTML/JSX,
which causes unexpected behaviors. This issue is now fixed.
<!-- prettier-ignore -->
```md
<!-- Input -->
_foo <InlineJSX /> bar_
<!-- Output (Prettier 1.16.0) -->
_foo
<InlineJSX /> bar_
<!-- Output (Prettier 1.16.1) -->
_foo <InlineJSX /> bar_
```
[@​ikatyang]: https://togithub.com/ikatyang
[@​simenb]: https://togithub.com/SimenB
[#​5778]: https://togithub.com/prettier/prettier/pull/5778
[#​5783]: https://togithub.com/prettier/prettier/pull/5783
[#​5785]: https://togithub.com/prettier/prettier/pull/5785
[#​5790]: https://togithub.com/prettier/prettier/pull/5790
### [`v1.16.0`](https://togithub.com/prettier/prettier/blob/master/CHANGELOG.md#​1160)
[Compare Source](https://togithub.com/prettier/prettier/compare/1.15.3...1.16.0)
[diff](https://togithub.com/prettier/prettier/compare/1.15.3...1.16.0)
🔗 [Release Notes](https://prettier.io/blog/2019/01/20/1.16.0.html)
</details>
---
### Renovate configuration
📅 **Schedule**: "after 6pm every weekday,before 5am every weekday" in timezone America/Los_Angeles.
🚦 **Automerge**: Enabled.
♻️ **Rebasing**: Whenever PR is stale, or if you modify the PR title to begin with "`rebase!`".
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- renovate-rebase -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://togithub.com/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#apollographql/apollo-server).
* feat(fastify) Apollo Fastify server integration resolve#626
* feat(fastify) Use createHandler instead of applyMiddleware #626
* feat(fastify) Fix integration test for node 10 #626
* feat(fastify) Update README's with fastify createHandler interface #626
* feat(fastify) Implement the fastify createHandler as a synchronous method #626
* (fastify) Tweaks to re-align with the parallel work in #2054.
* (fastify): Use port 9999 rather than 8888 for tests. Because Gatsby.
This specific port per integration is pretty brittle to begin with, but it
does work. Currently, the fact that it works is facilitated by the fact
that most people don't use 5555 (Hapi) and 6666 (Express) for anything.
That said, the ever-popular Gatsby uses 8888 by default, so let's use 9999!
* (fastify) Remove duplicative assertion in upload initialization.
* (fastify) Implement fastify upload middleware
* (fastify) Fix linting issues
* (fastify) Update package-lock
In an effort to see how effective this cache is in production during this
alpha phase, we'll print out the stats on the document store every 60
seconds.
The implementation of object-size approximation which is used for cache
eviction purposes in the `InMemoryLRUCache` implementation (via `lru-cache`)
was a short-term location for extensible logic which is better located
within `ApolloServerBase`.
This is particularly important since future logic may necessitate knowing or
understanding the current size (roughly, memory usage) of the in-memory
storage. Effective immediately, this adds support for providing a `dispose`
function which is called when an object is purged from the cache to make
room for another.
While the implementation of the `documentStore` is currently simple enough
to never throw (it is in-memory), it makes some sense to guard against future
extended functionality where an exception might be raised.
Since storing this object in a distributed memory store isn't currently
feasible, I'm not sure what such an exception would be right now, but I
don't mind being proactive!
Ref: https://github.com/apollographql/apollo-server/pull/2111/files#r247618501
Without this change, the `document` property was not set on the
`requestContext` for consumption by request pipeline plugins.
To further guard against this oversight, I've removed the extra `document`
variable which was being used as scoped state for the document and switched to
directly using (and assigning to) the `requestContext.document`.
Nice catch, @glasser!
Ref: https://github.com/apollographql/apollo-server/pull/2111/files#r247617469
This specific port per integration is pretty brittle to begin with, but it
does work. Currently, the fact that it works is facilitated by the fact
that most people don't use 5555 (Hapi) and 6666 (Express) for anything.
That said, the ever-popular Gatsby uses 8888 by default, so let's use 9999!
* refactor: switch `json-stable-stringify` to `fast-json-stable-stringify`
* chore: drop `@types/json-stable-stringify`
* Update CHANGELOG.md for #2065.
This also re-enables the Expiration tests for this library, though I think I
will continue to leave the testsuite decomposed into more granular methods
for readability and future growth.
Note that this doesn't implement the same default `300` second TTL as the
other Memcache and Redis implementations currently do (a very debatable
default we should re-consider in the future).
While it is certainly our current implementation, I'm not sure that the true
spirit of an in-memory key-value store is to only map strings to other strings.
While enforcing `<string, string>` might be necessary for some distributed
cache stores, it seems we shouldn't enforce it for `InMemoryLRUCache`.
By changing the `KeyValueCache` to default to `string` but allow other
options, we can allow the user to decide exactly how the RHS of this store
should be typed.
This does require a bit more flexible implementation of the `length`
calculator which is used for cache ejection, but that implementation will
become immediately useful when we start storing parsed ASTs in this KV store.
