eslint-plugin-graphql

What is eslint-plugin-graphql?

eslint-plugin-graphql is an ESLint plugin that provides GraphQL linting rules for your JavaScript and TypeScript projects. It helps ensure that your GraphQL queries, mutations, and subscriptions are syntactically correct and follow best practices.

What are eslint-plugin-graphql's main functionalities?

Linting GraphQL Queries

This feature allows you to lint GraphQL queries within template strings. The configuration specifies the environment as 'literal' and uses a local schema file to validate the queries.

{
  "rules": {
    "graphql/template-strings": [
      "error",
      {
        "env": "literal",
        "schemaJson": require('./schema.json')
      }
    ]
  }
}

Linting GraphQL Files

This feature allows you to lint GraphQL operations in .graphql files. The configuration uses a local schema file to validate the operations and ensures that all operations are named.

{
  "rules": {
    "graphql/named-operations": [
      "error",
      {
        "schemaJson": require('./schema.json')
      }
    ]
  }
}

Custom Validation Rules

This feature allows you to enforce custom validation rules on your GraphQL queries. The example configuration ensures that every query includes the 'id' and '__typename' fields.

{
  "rules": {
    "graphql/required-fields": [
      "error",
      {
        "env": "apollo",
        "schemaJson": require('./schema.json'),
        "requiredFields": ["id", "__typename"]
      }
    ]
  }
}

Other packages similar to eslint-plugin-graphql

graphql-eslint

graphql-eslint is another ESLint plugin that provides a comprehensive set of rules for linting GraphQL schema and operations. It offers more granular control over linting rules and supports both GraphQL schema and operations in various file types. Compared to eslint-plugin-graphql, graphql-eslint provides a more extensive set of rules and better integration with GraphQL tools like Apollo and Relay.

README

eslint-plugin-graphql

An ESLint plugin that checks tagged query strings inside JavaScript, or queries inside .graphql files, against a GraphQL schema.

npm install eslint-plugin-graphql

eslint-plugin-graphql has built-in settings for three GraphQL clients out of the box:

1. Apollo client
2. Relay
3. Lokka
4. FraQL

If you want to lint your GraphQL schema, rather than queries, check out cjoudrey/graphql-schema-linter.

Importing schema JSON

You'll need to import your introspection query result or the schema as a string in the Schema Language format. This can be done if you define your ESLint config in a JS file.

Retrieving a remote GraphQL schema

graphql-cli provides a get-schema command (in conjunction with a .graphqlconfig file) that makes retrieving remote schemas very simple.

apollo-codegen also provides an introspect-schema command that can get your remote schemas as well

Common options

All of the rules provided by this plugin have a few options in common. There are examples of how to use these with Apollo, Relay, Lokka, FraQL and literal files further down.

• env: Import default settings for your GraphQL client. Supported values: 'apollo', 'relay', 'lokka', 'fraql' 'literal'. Defaults to 'apollo'. This is used for the slight parsing differences in the GraphQL syntax between Apollo, Relay, Lokka and FraQL as well as giving nice defaults to some other options.

• tagName: The name of the template literal tag that this plugin should look for when searching for GraphQL queries. It has different defaults depending on the env option:

  • 'relay': 'Relay.QL'
  • 'internal': Special automatic value
  • others: 'gql', 'graphql'

You also have to specify a schema. You can either do it using one of these options:

• schemaJson: Your schema as JSON.
• schemaJsonFilepath: The absolute path to your schema as a .json file. (Warning: this variant is incompatible with eslint --cache.)
• schemaString: Your schema in the Schema Language format as a string.

Alternatively, you can use a .graphqlconfig file instead of the above three options. If you do there's one more option to know about:

• projectName: In case you specify multiple schemas in your .graphqlconfig file, choose which one to use by providing the project name here as a string.

There's an example on how to use a .graphqlconfig file further down.

Identity template literal tag

This plugin relies on GraphQL queries being prefixed with a special tag. In Relay and Apollo, this is always done, but other clients often take query strings without a tag. In this case, you can define an identity tag that doesn't do anything except for tell the linter this is a GraphQL query:

global.gql = (literals, ...substitutions) => {
    let result = "";

    // run the loop only for the substitution count
    for (let i = 0; i < substitutions.length; i++) {
        result += literals[i];
        result += substitutions[i];
    }

    // add the last literal
    result += literals[literals.length - 1];

    return result;
}

Code snippet taken from: https://leanpub.com/understandinges6/read#leanpub-auto-multiline-strings

Note: The linter rule could be extended to identify calls to various specific APIs to eliminate the need for a template literal tag, but this might just make the implementation a lot more complex for little benefit.

GraphQL literal files

This plugin also lints GraphQL literal files ending on .gql or .graphql. In order to do so set env to 'literal' in your .eslintrc.js and tell eslint to check these files as well.

eslint . --ext .js --ext .gql --ext .graphql

Example config for Apollo

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'apollo',

      // Import your schema JSON here
      schemaJson: require('./schema.json'),

      // OR provide absolute path to your schema JSON (but not if using `eslint --cache`!)
      // schemaJsonFilepath: path.resolve(__dirname, './schema.json'),

      // OR provide the schema in the Schema Language format
      // schemaString: printSchema(schema),

      // tagName is gql by default
    }]
  },
  plugins: [
    'graphql'
  ]
}

Example config for Relay

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'relay',

      // Import your schema JSON here
      schemaJson: require('./schema.json'),

      // OR provide absolute path to your schema JSON (but not if using `eslint --cache`!)
      // schemaJsonFilepath: path.resolve(__dirname, './schema.json'),

      // OR provide the schema in the Schema Language format
      // schemaString: printSchema(schema),

      // tagName is set for you to Relay.QL
    }]
  },
  plugins: [
    'graphql'
  ]
}

Example config for Lokka

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'lokka',

      // Import your schema JSON here
      schemaJson: require('./schema.json'),

      // OR provide absolute path to your schema JSON (but not if using `eslint --cache`!)
      // schemaJsonFilepath: path.resolve(__dirname, './schema.json'),

      // OR provide the schema in the Schema Language format
      // schemaString: printSchema(schema),

      // Optional, the name of the template tag, defaults to 'gql'
      tagName: 'gql'
    }]
  },
  plugins: [
    'graphql'
  ]
}

Example config for FraQL

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'fraql',

      // Import your schema JSON here
      schemaJson: require('./schema.json'),

      // OR provide absolute path to your schema JSON
      // schemaJsonFilepath: path.resolve(__dirname, './schema.json'),

      // OR provide the schema in the Schema Language format
      // schemaString: printSchema(schema),

      // Optional, the name of the template tag, defaults to 'gql'
      tagName: 'gql'
    }]
  },
  plugins: [
    'graphql'
  ]
}

Example config for literal graphql files

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'literal',

      // Import your schema JSON here
      schemaJson: require('./schema.json'),

      // OR provide absolute path to your schema JSON (but not if using `eslint --cache`!)
      // schemaJsonFilepath: path.resolve(__dirname, './schema.json'),

      // OR provide the schema in the Schema Language format
      // schemaString: printSchema(schema),

      // tagName is set automatically
    }]
  },
  plugins: [
    'graphql'
  ]
}

Additional Schemas or Tags

This plugin can be used to validate against multiple schemas by identifying them with different tags. This is useful for applications interacting with multiple GraphQL systems. Additional schemas can simply be appended to the options list:

module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      env: 'apollo',
      tagName: 'FirstGQL',
      schemaJson: require('./schema-first.json')
    }, {
      env: 'relay',
      tagName: 'SecondGQL',
      schemaJson: require('./schema-second.json')
    }]
  },
  plugins: [
    'graphql'
  ]
}

Example config when using .graphqlconfig

If you have .graphqlconfig file in the root of your repo you can omit schema-related properties (schemaJson, schemaJsonFilepath and schemaString) from rule config.

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      // Import default settings for your GraphQL client. Supported values:
      // 'apollo', 'relay', 'lokka', 'fraql', 'literal'
      env: 'literal'
      // no need to specify schema here, it will be automatically determined using .graphqlconfig
    }]
  },
  plugins: [
    'graphql'
  ]
}

In case you use additional schemas, specify projectName from .graphqlconfig for each tagName:

module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      env: 'apollo',
      tagName: 'FirstGQL',
      projectName: 'FirstGQLProject'
    }, {
      env: 'relay',
      tagName: 'SecondGQL',
      projectName: 'SecondGQLProject'
    }]
  },
  plugins: [
    'graphql'
  ]
}

Selecting Validation Rules

GraphQL validation rules can be configured in the eslint rule configuration using the validators option. The default selection depends on the env setting. If no env is specified, all rules are enabled by default.

The validators setting can be set either to a list of specific validator names or to the special value "all".

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

The full list of available validators is:

• ExecutableDefinitions
• FieldsOnCorrectType
• FragmentsOnCompositeTypes
• KnownArgumentNames
• KnownDirectives (disabled by default in relay)
• KnownFragmentNames (disabled by default in all envs)
• KnownTypeNames
• LoneAnonymousOperation
• NoFragmentCycles
• NoUndefinedVariables (disabled by default in relay)
• NoUnusedFragments (disabled by default in all envs)
• NoUnusedVariables
• OverlappingFieldsCanBeMerged
• PossibleFragmentSpreads
• ProvidedRequiredArguments (disabled by default in relay)
• ScalarLeafs (disabled by default in relay)
• SingleFieldSubscriptions
• UniqueArgumentNames
• UniqueDirectivesPerLocation
• UniqueFragmentNames
• UniqueInputFieldNames
• UniqueOperationNames
• UniqueVariableNames
• ValuesOfCorrectType
• VariablesAreInputTypes
• VariablesDefaultValueAllowed
• VariablesInAllowedPosition

Named Operations Validation Rule

The Named Operation rule validates that all operations are named. Naming operations is valuable for including in server-side logs and debugging.

Pass

query FetchUsername {
  viewer {
    name
  }
}

Fail

query {
  viewer {
    name
  }
}

The rule is defined as graphql/named-operations.

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      env: 'apollo',
      schemaJson: require('./schema.json'),
    }],
    "graphql/named-operations": ['warn', {
      schemaJson: require('./schema.json'),
    }],
  },
  plugins: [
    'graphql'
  ]
}

Required Fields Validation Rule

The Required Fields rule validates that any specified required field is part of the query, but only if that field is available in schema. This is useful to ensure that query results are cached properly in the client.

Pass

// 'uuid' required and present in the schema

schema {
  query {
    viewer {
      name
      uuid
    }
  }
}

query ViewerName {
  viewer {
    name
    uuid
  }
}

Pass

// 'uuid' usually required but not present in the schema here

schema {
  query {
    viewer {
      name
    }
  }
}

query ViewerName {
  viewer {
    name
  }
}

Fail

// 'uuid' required and present in the schema

schema {
  query {
    viewer {
      uuid
      name
    }
  }
}

query ViewerName {
  viewer {
    name
  }
}

The rule is defined as graphql/required-fields and requires the requiredFields option.

// In a file called .eslintrc.js
module.exports = {
  rules: {
    'graphql/required-fields': [
      'error',
      {
        env: 'apollo',
        schemaJsonFilepath: path.resolve(__dirname, './schema.json'),
        requiredFields: ['uuid'],
      },
    ],
  },
  plugins: [
    'graphql'
  ]
}

Capitalization of a first letter of a Type name

This rule enforces that first letter of types is capitalized

Pass

query {
  someUnion {
    ... on SomeType {
      someField
    }
  }
}

Fail

query {
  someUnion {
    ... on someType {
      someField
    }
  }
}

The rule is defined as graphql/capitalized-type-name.

// In a file called .eslintrc.js
module.exports = {
  parser: "babel-eslint",
  rules: {
    "graphql/template-strings": ['error', {
      env: 'apollo',
      schemaJson: require('./schema.json'),
    }],
    "graphql/capitalized-type-name": ['warn', {
      schemaJson: require('./schema.json'),
    }],
  },
  plugins: [
    'graphql'
  ]
}

No Deprecated Fields Validation Rule

The No Deprecated Fields rule validates that no deprecated fields are part of the query. This is useful to discover fields that have been marked as deprecated and shouldn't be used.

Fail

// 'id' requested and marked as deprecated in the schema

schema {
  query {
    viewer {
      id: Int @deprecated(reason: "Use the 'uuid' field instead")
      uuid: String
    }
  }
}

query ViewerName {
  viewer {
    id
  }
}

The rule is defined as graphql/no-deprecated-fields.

// In a file called .eslintrc.js
module.exports = {
  rules: {
    'graphql/no-deprecated-fields': [
      'error',
      {
        env: 'relay',
        schemaJson: require('./schema.json')
      },
    ],
  },
  plugins: [
    'graphql'
  ]
}

Changelog

v3.0.0

• BREAKING: The required-fields rule has been significantly changed to make it a completely reliable method of ensuring an id field (or any other field name) is always requested when available. PR #199 Here is the behavior, let's say we are requiring field id:
  • On any field whose return type defines a field called id, the selection set must directly contain id.
  • In any named fragment declaration whose type defines a field called id, the selection set must directly contain id.
  • An inline fragment whose type defines a field called id must contain id in its selection set unless its parent is also an inline fragment that contains the field id.
  • Here's a specific case which is no longer valid:
    • query { greetings { hello ... on Greetings { id } } }
    • This must now be written as query { greetings { id hello ... on Greetings { id } } }
  • This is a more conservative approach than before, driven by the fact that it's quite hard to ensure that a combination of inline fragments actually covers all of the possible types of a selection set.
• Fix breaking change in graphql@^14.0.0 that renamed ProvidedNonNullArguments to ProvidedRequiredArguments #192
• Update dependencies to graphql-tools 4 and eslint 5.9 #193