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

Support the fragment spread group when defining alphabetize rule's groups #2291

Open
yoavsion opened this issue May 8, 2024 · 0 comments · May be fixed by #2293
Open

Support the fragment spread group when defining alphabetize rule's groups #2291

yoavsion opened this issue May 8, 2024 · 0 comments · May be fixed by #2293

Comments

@yoavsion
Copy link

yoavsion commented May 8, 2024

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:

'@graphql-eslint/alphabetize': [
  'error',
  {
    groups: ['id', '*', '...'],
    selections: ['OperationDefinition', 'FragmentDefinition'],
  },
]

So that this selection set:

{
  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.

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 a pull request may close this issue.

1 participant