You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'd like to be able to use the alphabetize graphql-eslint rule, and keep all fragment spreads grouped together, preferably at the end of the selection set.
Describe the solution you'd like
The rule already supports the groups option, which supports any literal string or the '*' string for "everything else."
I'd like to be able to configure the rule this way:
{
updatedAt
...SomeFragmentB
...SomeFragmentA
id
}
Would end up being alphabetized this way:
{
id
updatedAt
...SomeFragmentA
...SomeFragmentB
}
Since this line uses the node's name, the ... part of the spread is gone from the lexical comparison, which results in fragment spreads being sorted as if they were just regular field selections:
{
id
...SomeFragmentB
...SomeFragmentA
updatedAt
}
Describe alternatives you've considered
I've considered supporting regular expressions in the groups option, but that seemed like an overkill, even before I realized that ...SomeFragment is anyways treated as SomeFragment.
Additional context
Not much to add. I did code up a solution locally, mostly to understand how it ended up sorting items the way it did, but I'm waiting for a discussion on this issue to conclude before moving forward.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'd like to be able to use the alphabetize graphql-eslint rule, and keep all fragment spreads grouped together, preferably at the end of the selection set.
Describe the solution you'd like
The rule already supports the
groups
option, which supports any literal string or the'*'
string for "everything else."I'd like to be able to configure the rule this way:
So that this selection set:
Would end up being alphabetized this way:
Since this line uses the node's name, the
...
part of the spread is gone from the lexical comparison, which results in fragment spreads being sorted as if they were just regular field selections:Describe alternatives you've considered
I've considered supporting regular expressions in the
groups
option, but that seemed like an overkill, even before I realized that...SomeFragment
is anyways treated asSomeFragment
.Additional context
Not much to add. I did code up a solution locally, mostly to understand how it ended up sorting items the way it did, but I'm waiting for a discussion on this issue to conclude before moving forward.
The text was updated successfully, but these errors were encountered: