-
Notifications
You must be signed in to change notification settings - Fork 257
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 locations to composition errors #686
Add locations to composition errors #686
Conversation
2. make sure all test's use parse() instead of gql() so that the loc fields are populated on each type definition
…ocation & update tests
…cation & update tests
… location & update tests
…ations & update test
…hCode to get location & update test
…t locations & add test
…ons & update test
…get locations & update tests
…o get locations & update test
…ations & update tests
…de to get locations & update tests
…call to get locations & update tests
… get locations & update test
…Code to get locations & update test
…o get locations & update test
…e to get locations & update test
…ode to get locations & update test
…ode to get locations & update tests
…Code to get the location & update tests need to figure out why the tests don't print the errors as I expect
… errorWithCode to get locations & update tests
…ph nodes = locations for both subgraphs in location. updated tests
…hCodes = locations correspond to both services. updated tests
bc8e27a
to
fcb15c4
Compare
…ldDefinitionNodes
b512dbc
to
4a94b78
Compare
federation-js/src/composition/validate/sdl/__tests__/uniqueTypeNamesWithFields.test.ts
Outdated
Show resolved
Hide resolved
federation-js/src/composition/validate/postComposition/externalUnused.ts
Outdated
Show resolved
Hide resolved
federation-js/src/composition/validate/postComposition/keyFieldsSelectInvalidType.ts
Outdated
Show resolved
Hide resolved
extendingServiceTypeNode && 'directives' in extendingServiceTypeNode ? | ||
extendingServiceTypeNode.directives?.find(directive => | ||
directive.name.value === 'key')?.arguments?.find | ||
(argument => argument.name.value === 'fields') : undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the nodes we want in this case are each of the @key
directives on the extended type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this one, since we can't select the general "directive area" I am going to select the type node, so the error can be located to the whole error where there are too many @key
s.
federation-js/src/composition/validate/postComposition/__tests__/providesNotOnEntity.test.ts
Outdated
Show resolved
Hide resolved
…tch, externalUsedOnBase
…pecific in the case where the error is about the number of key directives
Okay I spent time today doing a full search through all the codes to make sure the locations make sense, which meant a few more changes than were requested. I'm hoping this looks pretty good 😋 . Excited about this! @trevor-scheer |
federation-js/src/composition/validate/postComposition/__tests__/externalUnused.test.ts
Outdated
Show resolved
Hide resolved
federation-js/src/composition/validate/postComposition/externalMissingOnBase.ts
Show resolved
Hide resolved
| FieldDefinitionNode | ||
| SchemaDefinitionNode | ||
| FieldNode | ||
| DefinitionNode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the direction you're taking this. I will suggest, I think we should either go full bore Maybe<ASTNode>
as the type or only permit types which at least have a directives
property on them. I like the latter, since the typings will warn users of the fn when they're using it inappropriately. In your case, the only inappropriate usage which is now included in this union is the DirectiveDefinitonNode
, so I'll suggest this (+ a nice little TS revamp since we're here)
export function findDirectivesOnNode(
node: Maybe<
Exclude<
| FieldDefinitionNode
| InputValueDefinitionNode
| FieldNode
| DefinitionNode,
DirectiveDefinitionNode
>
>,
directiveName: string,
) {
return (
node?.directives?.filter(
(directive) => directive.name.value === directiveName,
) ?? []
);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, I think I'll go with enumerating all the AST type with directives if that sounds good, rather than excluding from the ASTNode, since there aren't actually too many Types with directives
.
export function findSelectionSetOnNode( | ||
node: Maybe< | ||
| FieldDefinitionNode | ||
| DefinitionNode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same Exclude<>
type I suggested above would give you a similar ergonomic win here.
? node.directives.filter( | ||
directive => directive.name.value === directiveName, | ||
) | ||
: []; | ||
} | ||
|
||
export function findSelectionSetOnNode( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fn is a bit tough to grok. Can you please add a good description to what this fn looks for and how?
return node && 'directives' in node && node.directives | ||
? node.directives.find( | ||
directive => | ||
directive.name.value === directiveName && directive.arguments?.some( | ||
argument => argument.value.kind === "StringValue" && | ||
argument.value.value.includes(elementInSelectionSet) | ||
))?.arguments?.find( | ||
argument => argument.name.value === 'fields')?.value | ||
: undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- we should use
Kind.STRING
for"StringValue"
(or use theisStringValueNode
predicate fn!) - I'm not totally sure I understand this correctly but I think I do. Is the
includes
here possibly error-prone?
I'm imagining 2 keys:
@key(fields: "id")
@key(fields: "sku { id }")
Could this scenario break this implementation? I might be mistaken and just need to understand this a bit better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the scenario you described:
type SomeType @key(fields: "id") @key(fields: "sku { id }") {
and we are looking for the field with id
on it, yeah this would break. If this were the case, and we wanted to find a top level field, would it be sufficient to make sure that string is not wrapped in curly braces? I'll write a test for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The resolution here was to search for the entire selection set, so we know we are selecting the correct key.
…single field. Update test name to be plural & write definition for selection set search
0fc8d54
to
0b5a188
Compare
argument => argument.value.kind === "StringValue" && | ||
argument.value.value.includes(elementInSelectionSet) | ||
argument => isStringValueNode(argument.value) && | ||
argument.value.value.includes(printedSelectionSet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be ===
now instead of includes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it!
Can we also replace the printFieldSet
fn in printSupergraphSdl
with the one we've moved into the utils
file?
@trevor-scheer just pushed those last changes, I think you have to merge :) Woohoo! |
01642f6
to
46bd00c
Compare
…SelectionSetOnNode
46bd00c
to
606a341
Compare
|
@mayakoneval this is probably not a you problem - I'll take a look at the errors in a bit. You might also try merging in |
@mayakoneval I merged main which must've introduced some good TS changes since I then had to remove a couple unused imports. Now everything is passing, so I'm going to land this now 🎉 |
This PR
gql
function stripsloc
information from the type definitions that it returns, so all tests that I edited useparse
instead ofgql
.errorWithCode
which calls theGraphQLError
constructor. Ifnode
is provided to theGraphQLError
constructor with aloc
field onnode
with asource
onloc
, the location information added to an error is the same as the location information on node. This took me a while to get :)composeAndValidate
into thedescribe('error
because that seemed more fitting 🤷 I would be fine deleting this one if anyone disagrees.composeAndValidate.test.ts
andcompose.test.ts
I recommend reviewing by commit
Please let me know of any concerns switching
gql
toparse
.Questions