Feature Request: Filtering GraphQL-file schema-linters by extension (as an option)

[fbartho]

trafficstars

I have 2 sets of graphql files that apply to different schemas.

These are distinguished via different extensions (something like): Foo.apiOne.graphql Bar.apiTwo.graphql. I'd like to configure the ESLint for graphql-literal files so that it lints *.apiOne.graphql differently than *.apiTwo.graphql files.

This is doable on the command line via passing the --ext .apiOne.graphql flag, but this doesn't help with in-editor listing in VSCode.

This means that today, tagged-template strings are significantly more powerful way to use this plugin than graphql files.

I'd be nice if I could specify the --ext that a particular rule set applies to, and pass a series of rulesets for different schemas.

[fbartho]

This would be a more general solution to #107

[jnwng]

@fbartho unfortunately ESLint doesn't have a way to configure linting per file extension, which makes more "official" support difficult.

however, we already have the concept of multiple configurations for associating different schemas to different tagNames, so i dont think it would be too far-fetched to extend the literal configuration to have an file extension configuration for the same purpose (a different schema / ruleset for different file extensions).

this might look something like:

module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      env: 'literal',
      tagName: '.apiOne.graphql',
      schemaJson: require('./schema-first.json')
    }, {
      env: 'literal',
      validators: 'all',
      extension: '.apiTwo.graphql',
      schemaJson: require('./schema-second.json')
    }]
  },
  plugins: [
    'graphql'
  ]
}

does that sound like it would resolve the issue you're having using standalone .graphql files?

[fbartho]

For me, this sounds like it would totally solve my problems. @jnwng

[jnwng]

@fbartho follow-up question — in this case, you won't be able to configure different warning level for different extensions (e.g., if graphql/template-strings is "error", it will be "error" for all extensions). is the only use-case here to use different schemas for different GraphQL files? or do you want to be able to use different rules?

[fbartho]

@jnwng That sounds fine! -- Selfish of me, but I actually want one of the extensions not to validate at all while the other extension validates. -- I'd be fine with your suggestions, but I don't know if other users would want something different.

Full Transparency: I'm working with apollo-link-rest & apollo-link-state. -- Neither of these connects to an actual GraphQL server, so I'm writing my own "server-side schemas" for them, then code-generating them into schema.json -- this output of the processing the first graphql files (containing the types) is expected to validate the second set of graphql files (which contain simply the queries/fragments). I don't think there's any way I could validate the first set (other than at Basic GraphQL syntax level), so I would be fine turning off validation for them. I'm only doing schema stitching as a technique to modularize my .graphql files.

[emmenko]

In case it helps others, for a multi project setup I managed to make it work like this:

In .graphqlconfig.yml

projects:
  api-one:
    schemaPath: schema/api-one.json
    includes:
      - '**/*.api-one.graphql'
    extensions:
      endpoints:
        production:
          url: https://api-one.com/graphql
  api-two:
    schemaPath: schema/api-two.json
    includes:
      - '**/*.api-two.graphql'
    extensions:
      endpoints:
        production:
          url: https://api-two.com/graphql

The important part is the includes, where you specify which files should match which schema. Note that the *.graphql files should be prefixed with some sort of identifier for one of the schemas (e.g. *.api.one.graphql).

The eslint rule is simply:

rules:
  graphql/template-strings:
    - error
    - env: literal

To get the schemas, simply run graphql get-schema, which will use the config in .graphqlconfig.yml.