@therealgilles since the filename used for the generated chunks in this plugin always uses “document.graphql” (see https://github.com/dotansimha/graphql-eslint/blob/master/packages/plugin/src/processors/code-files.ts#L42), you can make a rule specific for these generated chunks without affecting your other “.graphql” files (assuming none of them are called “document.graphql”). I’ve done this in my eslint config which uses this parser to turn off the eol rule that was breaking for these generated chunks.

Here’s a snippet of what I have which seems to work:

{
    "files": ["*.gql", "*.graphql"],
    "parser": "@graphql-eslint/eslint-plugin",
    "plugins": ["@graphql-eslint"],
    "rules": {
        "@graphql-eslint/naming-convention": [
            "error",
            {
                "ObjectTypeDefinition": "PascalCase",
                "FieldDefinition": "camelCase",
                "EnumValueDefinition": "UPPER_CASE",
                "InputValueDefinition": "camelCase",
                "FragmentDefinition": "camelCase",
                "leadingUnderscore": "allow"
            }
        ],
        "@graphql-eslint/require-deprecation-reason": "error",
        "@graphql-eslint/no-case-insensitive-enum-values-duplicates": "error"
    }
},
{
    "files": ["*document.graphql"],
    "rules": {
        "eol-last": "off"
    }
},

I suspect if you adjusted your above config as follows it should work ok.

[
  {
    "files": ["*.tsx", "*.ts", "*.jsx", "*.js"],
    "processor": "@graphql-eslint/graphql"
  },
  {
    "files": ["*.graphql"],
    "parser": "@graphql-eslint/eslint-plugin",
    "plugins": ["@graphql-eslint"],
    "rules": {
      "@graphql-eslint/no-anonymous-operations": "error"
    }
  },
  {
    "files": ["*document.graphql"],
    "rules": {
      "prettier/prettier": "off"
    }
  }
]

Fixed in https://github.com/dotansimha/graphql-eslint/pull/225 Thank you @peterp @ilyavolodin @EmrysMyrddin @lavigneer @jgoux @huw 😃

Available @graphql-eslint/eslint-plugin@0.5.0.

Ran into the same issue—interop with the Prettier plugin is really important to me so I’m keen to see this solved!

I was running into the same issue and did a little digging. Apparently eslint always forces a child sub-path to be used when a custom processor is defined. The prettier plugin tries to read the file with this sub-path but it doesn’t actually exist.

There’s an issue open to give rules the opportunity to fetch the real filename but it hasn’t been addressed: https://github.com/eslint/eslint/issues/11989

In https://github.com/eslint/eslint/issues/11989#issuecomment-511261819 you can see how it builds the path.

One workaround I tried with the processor defined in this repo was to force the resolved path from path.join to be the true filename for the full file block that’s returned:

diff --git a/packages/plugin/src/processors/code-files.ts b/packages/plugin/src/processors/code-files.ts
index 19a51b5..8708ba3 100644
--- a/packages/plugin/src/processors/code-files.ts
+++ b/packages/plugin/src/processors/code-files.ts
@@ -1,4 +1,4 @@
-import { extname } from 'path';
+import { extname, basename } from 'path';
 import { parseCode } from '@graphql-tools/graphql-tag-pluck';
 import {} from 'eslint';
 
@@ -20,6 +20,8 @@ export function createGraphqlProcessor() {
       const blocks: Block[] = [];
       blocksMap.set(filename, blocks);
 
+      const resolvedFilename = `/../../${basename(filename)}`
+
       if (
         filename &&
         text &&
@@ -44,13 +46,13 @@ export function createGraphqlProcessor() {
             });
           }
 
-          blocks.push({ text, filename });
+          blocks.push({ text, filename: resolvedFilename, lineOffset: 0 });
 
           return blocks;
         }
       }
 
-      return [{ text, filename }];
+      return [{ text, filename: resolvedFilename, lineOffset: 0 }];
     },
     postprocess: (messageLists: any[], filename: string): any[] => {
       const blocks = blocksMap.get(filename);

This seems to work for my case but it feels pretty hacky. @dotansimha I’m not sure if this is something you’d want added? I can open a PR with the changes if you think it’s fine to go in here.

I should note, this still requires turning off the prettier/prettier rule for the extracted code blocks from these files, as was suggested in https://github.com/dotansimha/graphql-eslint/issues/88#issuecomment-706666698

On a side note, after doing all this I still had issues with the extracted code blocks failing on the “eol-last” rule in my config. This can be fixed by adding this to the overrides array:

{
    "files": ["*document.graphql"],
    "rules": {
        "eol-last": "off"
    }
}

UPDATE

I located the issue. It’s because the project has a root .eslintrc and several nested .eslintrc in various directories.

The override entry that disables the eol-last rule on *.graphql files was being overridden by the nested configs.

Moving the override into the nested config files solved the issue. Thanks @lavigneer

---

Original post:

@lavigneer unfortunately that didn’t work for me, I’m still seeing eol-last errors even after many attempts to disable them, including disabling

  {
    "files": ["*document.graphql"],
    "rules": {
      "eol-last": 0,
    }
  }

It also does not disable when matching all *.graphql files

"files": ["*.graphql"],

I don’t understand what could be going wrong

If you are using plugins using file system, you should use overrides to avoid using this plugins on .graphql and only on .js files.

Is this issue not fixed? I’m seeing ENOTDIR: not a directory errors in the VS Code ESLint output, using @graphql-eslint/eslint-plugin@0.6.1-alpha-bbfee02.0:

[Info  - 7:21:56 PM] ENOTDIR: not a directory, stat '/[redacted]/index.js/0_document.graphql' Occurred while linting /[redacted]/index.js/0_document.graphql:0

Not sure eslint-plugin-html is working around the same problem here. It is complaining about the lack of access to eslint config from processor.

Naming processed chunks with the original filename would work, however, there might be some issues with this if there are multiple chunks generated from a single file. That will mean that original file will be ran through prettier multiple times. The other option to deal with this would be to name processor chunks using some sort of convention and then modify prettier rule to look for that convention and instead of trying to resolve config/ignore based on the chunk name, restore original file name instead. I.e. for example, if original file was named index.ts you could change processor to name chunks index|ts-chunk1.graphql, then prettier rule could be modified to restore index.ts filename and run prettier config resolution and ignore checks based on index.ts and not on the chunk.graphql.

That solved it! Thanks!