Add patch package to apply diff changes to schemas #2893
Conversation
| meta: { | ||
| directiveName: oldDirective.name, | ||
| oldDirectiveDescription: oldDirective.description ?? null, | ||
| directiveName: newDirective.name, |
There was a problem hiding this comment.
In these cases, the type is being used to extract the name only. It doesn't matter if we pass the new or old directive, since the name is the same. However, since calling these functions onAdd -- the old type can be null, which is why this was changed to pass the new type (newDirective)
|
|
||
| { | ||
| const change = findFirstChangeByPath(changes, 'enumA.A'); | ||
| expect(change.criticality.level).toEqual(CriticalityLevel.NonBreaking); |
There was a problem hiding this comment.
This test shows that enum additions also contain all nested changes within that enum, and that those changes are flagged as non-breaking.
| return { | ||
| type: ChangeType.FieldDeprecationRemoved, | ||
| criticality: { | ||
| // @todo: Add a reason for why is this dangerous... Why is it?? |
There was a problem hiding this comment.
^ very curious why... It doesn't change behavior/how clients interact. "Dangerous" seems extreme.
There was a problem hiding this comment.
@kamilkisiela @dotansimha maybe you know 👯♂️
| parentType: type, | ||
| field: newField, | ||
| }), | ||
| directiveUsageAdded( |
There was a problem hiding this comment.
Should this filter out the deprecated directive since that's captured by another change?
jdolle
changed the title
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| '@graphql-inspector/core': major | |||
There was a problem hiding this comment.
I could be convinced that this is a minor patch because the changes to the output doesn't change the existing format/definitions -- only their content such as the paths.
However, the content changes are significant, which is why I thought we should be safe and declare a major change.
There was a problem hiding this comment.
For the output changes, we need to see how we can introduce this backwards-compatible into Hive, Consoewhile still supporting the old "changes". Have you thought about this already, and might it become an issue?
There was a problem hiding this comment.
I general I think this changeset could be much more detailed on changes, like what new types are there, how does it affect other types. But ofc this can be delayed until everything else is "complete".
There was a problem hiding this comment.
we need to see how we can introduce this backwards-compatible into Hive Console
Agreed. My strategy is to make the new fields optional in Hive Console. If I'm careful about it, this should let us safely migrate without breaking any existing change logic.
There was a problem hiding this comment.
I've added a much more detailed changelog message but didn't go to the length of listing every single field being changed.
If there's a case for listing every single field being changed, then I can do that. Or maybe it would be better suited for a migration guide?
jdolle
changed the title
| enumName: string; | ||
| addedDirectiveName: string; | ||
| addedToNewType: boolean; | ||
| directiveRepeatedTimes: number; |
There was a problem hiding this comment.
My thought from seeing this property here for the first time: It is not obvious to what it means. Maybe it could be named better, or a comment you give some context. I am sure when I get to looking T the actual implementation it will make sense though.
There was a problem hiding this comment.
maybe instanceNumber? It's for repeat directives -- I track which instance of a specific directive these changes apply to. This was the best solution I could come up with because it lets me modify specific instances, but avoids unnecessary conflicts if other directives are added before.
E.g. type Foo => type Foo @bar @bar @bar would have 3 added directives, with "instanceNumber"s 1, 2, then 3 respectively.
| // @question should this be separate change events for every case for safety? | ||
| export function directiveUsageChanged( |
There was a problem hiding this comment.
My first thought here is that we would want to have a remove and add change event instead? 🤔
There was a problem hiding this comment.
We have separate remove and add events. I think my question was unclear.
I mean should there be a unique DirectiveUsageArgumentAdded type for every node type: Object, Enum, Field, Argument, EnumValue, etc...
This would mean the meta could be simpler. Currently, to handle all cases it contains:
parentTypeName
parentFieldName
parentArgumentName
parentEnumValueName
But it would also mean a lot of extra cruft that we already have a ton of.
|
NIT: I see a lot of |
Adjusted |
2 participants
Description
This change began as one to only the adds fields that are necessary for recreating the patched schema using the input schema and changes array, but it has expanded to also add the patch functionality. I found this was necessary in order to verify that the changes provided sufficient data.
This PR modifies the several change types, and modifies the
onAddedhandlers to also execute equivalent logic toonMutual. It also adds a new rule that can be added to filter out these additional changes, thus keeping changelogs to a minimum. Paths also needed changed to consistently and uniquely map to the node being changed. Previously, some changes referenced a parent's coordinate. Lastly, directives support was dramatically improved and the directive path was modified to include@to distinguish it from any other node potentially with the same name.The expansion of "onAdded" has a few down sides and an important up side.
Cons
onAddedcall. Because e.g. adding an interface to newly create object is completely safe, but adding an interface to an existing object is considered dangerous.Pro
Type of change
How Has This Been Tested?
See unit tests.
Checklist:
CONTRIBUTING doc and the
style guidelines of this project