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.
In large projects fragment/query/mutation names become pretty verbose when you need to avoid name clashes.
Since near-operation-file generates fairly self-contained files, it should not really require the names to be globally unique, as long as there are no clashes within the generated file.
I'm not entirely sure this is even a problem for queries and mutations, but it is for fragments.
Describe the solution you'd like
Instead of figuring out the path to the file containing a fragment based on the name in a global context, the fragment file should be found based on the file being generated. Ideally this would work by looking at the imports in the source file.
Describe alternatives you've considered
If it is not possible to analyze the imports of the source file, perhaps some kind of solution where it picks the file based on the relative "closeness" to the source file, however such a solution would be fairly unreliable.
Additional context #2139 added an error when there are duplicate fragment names in the global context. This feature would remove the need for such a check, and instead "do the right thing"
The text was updated successfully, but these errors were encountered:
I don't quite agree with that. This issue relates to fragments, not queries and mutations.
The problem is, if you have two fragments named the exact same thing, and reference both from two different queries, one of them will reference the wrong fragment, because the path to the fragment is tied to the name.
I see @mvestergaard , but we can't tell which fragment is the relevant one and the correct one to use, because GraphQL spec doesn't have imports - so you either put it in the same file, or put it in another file, and use the fragment name.
So while we can support duplicate naming for queries and mutations, we can't really do that with fragments :(
Is your feature request related to a problem? Please describe.
In large projects fragment/query/mutation names become pretty verbose when you need to avoid name clashes.
Since near-operation-file generates fairly self-contained files, it should not really require the names to be globally unique, as long as there are no clashes within the generated file.
I'm not entirely sure this is even a problem for queries and mutations, but it is for fragments.
Describe the solution you'd like
Instead of figuring out the path to the file containing a fragment based on the name in a global context, the fragment file should be found based on the file being generated. Ideally this would work by looking at the imports in the source file.
Describe alternatives you've considered
If it is not possible to analyze the imports of the source file, perhaps some kind of solution where it picks the file based on the relative "closeness" to the source file, however such a solution would be fairly unreliable.
Additional context
#2139 added an error when there are duplicate fragment names in the global context. This feature would remove the need for such a check, and instead "do the right thing"
The text was updated successfully, but these errors were encountered: