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

Fix bug with type extension of empty type definition #1821

Merged
merged 3 commits into from
May 4, 2022

Conversation

pcmanus
Copy link
Contributor

@pcmanus pcmanus commented May 3, 2022

It is valid graphQL to do:

type Foo

extend type Foo {
  bar: Int
}

and while that's uncommon, this could be the convenient when mechanically concatenating files.

This wasn't handled correctly however as the code was not preserving the empty type definition and was thus considering the schema as just:

extend type Foo {
  bar: Int
}

which, when trying to compose this, may lead into an error complaining that the type is extended but has no definition (which is obviously incorrect).

@netlify
Copy link

netlify bot commented May 3, 2022

👷 Deploy request for apollo-federation-docs pending review.

Visit the deploys page to approve it

Name Link
🔨 Latest commit 77ea570

@codesandbox-ci
Copy link

codesandbox-ci bot commented May 3, 2022

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

@@ -878,6 +878,30 @@ describe('@core/@link handling', () => {
// Just making sure this don't error out.
buildAndValidate(doc);
});

it('allows defining a repeatable directive as non-repeatable but validates usages', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reviewer notes: this test is unrelated to the issue and it wasn't meant to be here, but I just wrote it earlier (to prove to myself that the behaviour of the test does work as the test shows) and didn't noticed it was there. But seeing it now, I'm thinking: "it's a nice test to have and is it really worth opening a separate PR for this?". Happy to remove though if it bothers someone.

type = schema.addType(newNamedType(withoutTrailingDefinition(definitionNode.kind), definitionNode.name.value));
} else if (type.preserveEmptyDefinition) {
// Note: we reuse the same error message than graphQL-js would output
throw new GraphQLError(`There can be only one type named "${definitionNode.name.value}"`);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reviewer note: writing this, I realised that we weren't validating this properly. That is:

type Foo {
  bar: Int
}

type Foo {
  baz: Int
}

was not erroring out, even though it should as it's not valid graphQL. So took the liberty to fix as well (and there is a test for it).

@benweatherman benweatherman added this to the 2.0.3 milestone May 3, 2022
Copy link
Contributor

@benweatherman benweatherman left a comment

Choose a reason for hiding this comment

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

🐐

@pcmanus pcmanus merged commit f9b3aaa into apollographql:main May 4, 2022
@benweatherman benweatherman mentioned this pull request May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants