Incorrect behaviour with operations in .js/.ts files

Describe the bug The @graphql-eslint/unique-fragment-name, @graphql-eslint/unique-operation-name, and @graphql-eslint/known-fragment-names rules seem to incorrectly report errors when operations are defined in .js/.ts files.

To Reproduce Steps to reproduce the behavior:

https://github.com/mikew/graphql-eslint-woes

Expected behavior There should be no issues in the repo above.

Environment:

• OS: macOS
• @graphql-eslint/...: latest
• NodeJS: 14

[B2o5T]

The false positive issue with known-fragment-names - currently it’s not possible to handle string interpolation because graphql-tag-pluck doesn’t support it (we use graphql-tag-pluck under the hood for extract documents from js/ts files)

And the issue with unique-fragment-name and unique-operation-name I’ll fix this week

[dotansimha]

Thanks for looking into this so quickly! Curious, what about the loadSiblings snippet above seems strange?

We have 3 different kinds of files loaded in this plugin:

1. Regular .graphql file - loaded with ESLint core using the plugin, and then we parse it with GraphQL and convert it to ESTree.
2. Code files with GraphQL code - we call these “virtual files” since we use ESLint processor to extract these from JS/TS files, and then we can a virtual file path (that doesn’t exists in FS).
3. Siblings - these are operations loaded as “siblings” to either regular file or virtual files, and they are in use in order to support or enrich the plugins with more info (For example, you might use ESLint for lining a GraphQL file with a query, but if that query is using a fragment spread, we have a mechanism that loads the fragment)

The snippet @B2o5T mentioned is the one that compares file paths while loading siblings. When it’s loaded against while linting a virtual file, we probably compare it in the wrong way (maybe we should use the original file path, not the virtual?).