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

from graphql-eslint.

Fixed in #225
Thank you @peterp @ilyavolodin @EmrysMyrddin @lavigneer @jgoux @huw :)

Available @graphql-eslint/[email protected].

from graphql-eslint.

@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"
    }
  }
]

from graphql-eslint.

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: eslint/eslint#11989

In eslint/eslint#11989 (comment) 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 #88 (comment)

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"
    }
}

from graphql-eslint.

That solved it! Thanks!

from graphql-eslint.

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.

from graphql-eslint.

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.

from graphql-eslint.

Is this issue not fixed? I'm seeing ENOTDIR: not a directory errors in the VS Code ESLint output, using @graphql-eslint/[email protected]:

[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

from graphql-eslint.

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

from graphql-eslint.

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

from graphql-eslint.

@peterp I think some rules/plugins doesn't play along with processor feature, probably because of the sub-paths that ESLint creates for those.
I noticed that with prettier/prettier for example, do you use it? if so, can you try to disable it?

      {
        "files": ["*.graphql"],
        "parser": "@graphql-eslint/eslint-plugin",
        "plugins": ["@graphql-eslint"],
         "rules": {
            "prettier/prettier": "off"
         }
      }

from graphql-eslint.

Great :) Thank you for the feedback @peterp !
I'm keeping open so it will be easier to track, still not sure if it's something we are doing in a wrong way, or something with the prettier plugin for eslint.

from graphql-eslint.

Hello, disabling prettier within the overrides array doesn't work for me.
Here is my config : https://gist.github.com/jgoux/3cc3f56f367a3b485d3bb8cb7fc55821

from graphql-eslint.

@lavigneer This is a solid one. Awesome work :)

@ilyavolodin you are the eslint expert ;) any idea how other plugins/parser deals with partial pre-processed files?

I think this might work, just need to make sure that all other features (code files / .graphql files) still working, I think it might mess some stuff there.

In the meantime, I will add this to the docs, to make sure people are aware of the config changes.

from graphql-eslint.

It seems that this issue is also making graphql-eslint incompatible with import which allow to warn about wrong import paths.

Your proposition @ilyavolodin will not work for this plugin, since it relies on the folder structure to check for unresolved imports. Blocks filename are always append as if the original file was a folder.

@lavigneer workaround is better since it also allow to restore the correct folder structure for the original file when linted by other plugins.

Eslint seems to think about a way to make preprocessors more compatible with current state of plugins ecosystem (eslint/eslint#11989).

Perhaps we can apply @lavigneer workaround waiting for an official eslint solution.

from graphql-eslint.

@EmrysMyrddin You could still have prettier strip out last part of the path if it follows specific convention and lint the resulting path. So the original file path was /user/project/index.ts, chunk path is going to be /user/project/index.ts/chunk.graphql. Inside prettier rule, if you can determine that the file name follows some specific convention, let's say chunk#.graphql, then you can revert the path back to /user/project/index.ts and pass it over to prettier. You would also want to maintain the cache of files that you already processed, so you wouldn't end up sending the same file to prettier more then once, that can be done through a singleton.

from graphql-eslint.

Yes, it's a possibility, but you will have to do this with every plugin relying on actual filesystem to work.

Without an official position on this from Eslint, I don't think plugin authors will follow.

from graphql-eslint.

That's true. Naming postfixing for chunks were added quite a bit after I wrote processor functionality for ESLint, so I'm not entirely sure what problem it was trying to fix, to be honest.

from graphql-eslint.

So perhaps we can add this little workaround, which is not perfect at all, but better than nothing while waiting for a real solution.

I have read the issue on Eslint side and it seems there isn't a lot of discution around it right now. Perhaps you can add your thought on it ? (eslint/eslint#11989)

from graphql-eslint.

I think eslint-plugin-html is doing a workaround to get this working? https://github.com/BenoitZugmeyer/eslint-plugin-html/blob/f33a88eaa17bab7f1864994dc998fa462c29e0b1/src/index.js#L16

from graphql-eslint.

Awesome ! thank you for your quick responses !

from graphql-eslint.

@EmrysMyrddin: If I have separate .graphql files that I would still want to run prettier on, am I stuck without a solution for now? Also any reason why apollographql/eslint-plugin-graphql does not seem to suffer from this issue?

from graphql-eslint.

This issue should only concern graphql tags. If you have separate .graphql files, you should be able to run prettier without overrides.

The other l'inter doesn't have this problem because it doesn't uses Eslint processors. Therefore, they lack some features, like resolving a required field (like id for example) within a fragment declared in an other tag or file.

from graphql-eslint.

@EmrysMyrddin: My current config looks like this:

        [
          {
            files: ['*.tsx', '*.ts', '*.jsx', '*.js'],
            processor: '@graphql-eslint/graphql',
          },
          {
            files: ['*.graphql'],
            parser: '@graphql-eslint/eslint-plugin',
            plugins: ['@graphql-eslint'],
            rules: {
              'prettier/prettier': `off`, // FIXME: need to turn off prettier for now due to an eslint issue
              '@graphql-eslint/no-anonymous-operations': `error`,
            },
          },
        ]

The prettier rule override seems to apply to *.graphql files and not graphql tags. If I try to move the rule up to the javascript/typescript file part, I get the error. Am I doing something or am I misunderstanding your statement?

PS: Running prettier through VSCode or on the cmd line seems to work, so maybe I am misunderstanding the effect of disabling the rule.

from graphql-eslint.