Getting Started
Configuration
To get started, define an override in your ESLint config to apply this plugin to .graphql
files.
Add the rules you want applied.
Note: This step is necessary even if you are declaring operations and/or schema in code files.
{
"overrides": [
{
"files": ["*.graphql"],
"parser": "@graphql-eslint/eslint-plugin",
"plugins": ["@graphql-eslint"],
"rules": {
"@graphql-eslint/known-type-names": "error"
}
}
]
}
If your GraphQL definitions are defined only in .graphql
files, and you’re only using rules that
apply to individual files, you should be good to go 👍. If you would like use a remote schema or use
rules that apply across the entire collection of definitions at once, see
here.
Apply Plugin to GraphQL Definitions Defined in Code Files
If you are defining GraphQL schema or GraphQL operations in code files, you’ll want to define an additional override to extend the functionality of this plugin to the schema and operations in those files.
{
"overrides": [
+ {
+ "files": ["*.js"],
+ "processor": "@graphql-eslint/graphql"
+ },
{
"files": ["*.graphql"],
"parser": "@graphql-eslint/eslint-plugin",
"plugins": ["@graphql-eslint"],
"rules": {
"@graphql-eslint/known-type-names": "error"
}
}
]
}
Under the hood, specifying the @graphql-eslint/graphql
processor for code files will cause
graphql-eslint/graphql
to extract the schema and operation definitions from these files into
virtual GraphQL documents with .graphql
extensions. This will allow the overrides you’ve defined
for .graphql
files, via "files": ["*.graphql"]
, to get applied to the definitions defined in
your code files.
Extended Linting Rules with GraphQL Schema
Some rules require an understanding of the entire schema at once. For example, no-unreachable-types checks that all types are reachable by root-level fields.
To use these rules, you’ll need to tell ESLint how to identify the entire set of schema definitions.
If you are using graphql-config
, you are good to go.
graphql-eslint
integrates with it automatically and will use it to load your schema!
Alternatively, you can define parserOptions.schema
in the *.graphql
override in your ESLint
config.
The parser allows you to specify a .json
file / .graphql
files(s) / url / raw string to locate
your schema (We are using graphql-tools
to do that). Just add parserOptions.schema
to your
configuration file:
{
"files": ["*.graphql"],
"parser": "@graphql-eslint/eslint-plugin",
"plugins": ["@graphql-eslint"],
"rules": {
"@graphql-eslint/no-unreachable-types": "error"
},
+ "parserOptions": {
+ "schema": "./schema.graphql"
+ }
}
You can find a complete documentation of the
parserOptions
here.
Some rules require type information to operate, it’s marked in the docs for each rule!
Extended Linting Rules with Siblings Operations
While implementing this tool, we had to find solutions for a better integration of the GraphQL ecosystem and ESLint core.
GraphQL’s operations can be distributed across many files, while ESLint operates on one file at a time. If you are using GraphQL fragments in separate files, some rules might yield incorrect results, due the missing information.
To workaround that, we allow you to provide additional information on your GraphQL operations, making it available for rules while doing the actual linting.
To provide that, we are using graphql-tools
loaders to load your sibling operations and fragments,
just specify a glob expression(s) that points to your code/.graphql
files:
{
"files": ["*.graphql"],
"parser": "@graphql-eslint/eslint-plugin",
"plugins": ["@graphql-eslint"],
"rules": {
"@graphql-eslint/unique-operation-name": "error"
},
"parserOptions": {
+ "operations": "./src/**/*.graphql",
"schema": "./schema.graphql"
}
}