Join us from October 8-10 in New York City to learn the latest tips, trends, and news about GraphQL Federation and API platform engineering.Join us for GraphQL Summit 2024 in NYC
Docs
Start for Free

Schema Linter Rules

Reference for GraphOS linting rules with examples


This reference lists the rules that you can enforce with GraphOS schema linting, along with the code that returns for each rule violation.

Naming rules

These rules enforce naming conventions. Rules are categorized by the part(s) of your schema that they correspond to.

Fields

Types

These rules apply to all types that appear in a , including:

  • Objects
  • Interfaces
  • Inputs
  • Enums
  • Unions

Objects

Interfaces

Inputs and arguments

Enums

Directives

Composition rules
Since 2.4

Composition rules flag potential improvements to subgraph schemas used to compose a .

Inconsistent elements

These rules identity inconsistencies in , types, arguments, etc across . Such inconsistencies can disrupt or even break composition.

Compatibility

In some cases, inconsistency rules also indicate the compatibility of checked types. Two types are compatible if one is a non-nullable version, a list version, a subtype, or a combination of any of these of the other.

For example, the price fields in the example subgraphs below are inconsistent and incompatible because they use completely different types (Float vs String):

Subgraph A
type Product {
id: ID!
name: String
price: Float
}
Subgraph B
type Product {
id: ID!
name: String
price: String
}

These price fields in the example subgraphs below are inconsistent but compatible since both use Floats, but one is nullable and the other is the non-nullable list of Floats.

Subgraph A
type Product {
id: ID!
name: String
price: Float
}
Subgraph B
type Product {
id: ID!
name: String
price: [Float]!
}