Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add deprecation warnings for GraphQLExtension usage. #4135

Merged
merged 1 commit into from
May 19, 2020

Conversation

abernix
Copy link
Member

@abernix abernix commented May 18, 2020

This introduces a deprecation warning which will be emitted once per extension which is defined in the extensions parameter of an Apollo Server configuration.

With the introduction of the last missing integration point (willResolveField) via the recently landed #3988, the new Plugin API should now have all of the abilities (a super-set, in fact) of the prior graphql-extensions API.

Furthermore, rather than being undocumented, rather untested and largely experimental, the new plugin API is considered stable and well-understood in terms of what it aims to support. Its documentation and API are now considered part of the Apollo Server API and we will do our best to maintain first-class support for it, including the addition of new functionality as deemed necessary.

As of this commit, we will now print deprecation warnings one time per server start-up for each legacy extension. Since extensions were often defined as factory functions which were invoked on each request - and expected to return an instance of the extension by calling new on it - we limit this deprecation warning to once per start-up by attaching a Symbol to the constructor and skipping the warning when the Symbol is already present.

An alternative design might use a Map to track the constructors at the module-level within requestPipeline.ts, but I believe this should be functionally the same.

This introduces a deprecation warning which will be emitted once per
extension which is defined in the `extensions` parameter of an Apollo Server
configuration.

With the introduction of the last missing integration point
(`willResolveField`) via the recently landed
#3988, the new [[Plugin
API]] should now have all of the abilities (a super-set, in fact) of the
prior `graphql-extensions` API.

Furthermore, rather than being undocumented, rather untested and largely
experimental, the new plugin API is considered stable and well-understood in
terms of what it aims to support.  Its documentation and API are now
considered part of the Apollo Server API and we will do our best to maintain
first-class support for it, including the addition of new functionality as
deemed necessary.

As of this commit, we will now print deprecation warnings one time per
server start-up for _each_ legacy extension.  Since extensions were often
defined as factory functions which were invoked on each request - and
expected to return an instance of the extension by calling `new` on it - we
limit this deprecation warning to once per start-up by attaching a `Symbol`
to the `constructor` and skipping the warning when the `Symbol` is already
present.

An alternative design might use a `Map` to track the `constructor`s at the
module-level within `requestPipeline.ts`, but I believe this should be
functionally the same.

[Plugin API]: https://www.apollographql.com/docs/apollo-server/integrations/plugins/
Copy link
Member

@trevor-scheer trevor-scheer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@@ -399,6 +400,88 @@ describe('runQuery', () => {
}
}

describe('deprecation warnings', () => {
const queryString = `{ testString }`;
async function runWithExtAndReturnLogger(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants