Schema Linter Rules

What it does

Checks that all field names use camelCase.

Rationale

camelCase is a convention for field names in GraphQL.

Examples

type User {
  FirstName: String! # PascalCase
}

type User {
  firstName: String # camelCase
}

What it does

Checks that a field's name doesn't start with any of the following verbs: get, list, post, put, patch.

Rationale

Fields should not start with a verb, except for mutations. For mutation fields, it's best to use a verb that describes the specific action being performed, for example, create, delete, or edit.

Examples

type Query {
  getUsers: [User!]!
}

type Query {
  users: [User!]!
}

What it does

Checks that all type names use PascalCase.

Rationale

PascalCase is a convention for type names in GraphQL.

Examples

type streamingService { # camelCase
  id: ID!
}

type StreamingService { # PascalCase
  id: ID!
}

What it does

Checks that type names don't start with the prefix Type.

Rationale

Avoid using the redundant Type prefix to shorten your schema definitions and improve readability.

Examples

type TypeBook {
  title: String!
}

type Book {
  title: String!
}

What it does

Checks that type names don't use the suffix Type.

Rationale

Avoid using the redundant Type suffix to shorten your schema definitions and improve readability.

Examples

type BookType {
  title: String!
}

type Book {
  title: String!
}

What it does

Checks that object type names don't start with the prefix Object.

Rationale

Avoid using the redundant Object prefix to shorten your schema definitions and improve readability.

Examples

type ObjectBook {
  title: String!
}

type Book {
  title: String!
}

What it does

Checks that object type names don't use the suffix Object.

Rationale

Avoid using the redundant Object suffix to shorten your schema definitions and improve readability.

Examples

type BookObject {
  title: String!
}

type Book {
  title: String!
}

What it does

Checks that interface type names don't start with the prefix Interface.

Rationale

Avoid using the redundant Interface prefix to shorten your schema definitions and improve readability.

Examples

interface InterfaceBook {
  title: String
  author: String
}

interface Book {
  title: String
  author: String
}

What it does

Checks that interface type names don't use the suffix Interface.

Rationale

Avoid using the redundant Interface suffix to shorten your schema definitions and improve readability.

Examples

interface BookInterface {
  title: String
  author: String
}

interface Book {
  title: String
  author: String
}

What it does

Checks that argument names use camelCase.

Rationale

camelCase is a convention for argument names in GraphQL.

Examples

type Mutation {
  createBlogPost(BlogPostContent: BlogPostContent!): Post # PascalCase
}

type Mutation {
  createBlogPost(blogPostContent: BlogPostContent!): Post # camelCase
}

What it does

Checks that input type names use the suffix Input.

Rationale

Ending input type names with Input distinguishes input types from "output" types like objects.

Examples

input BlogPostDetails {
  title: String!
  content: String!
}

input BlogPostDetailsInput {
  title: String!
  content: String!
}

What it does

Checks that enum values use SCREAMING_SNAKE_CASE.

Rationale

SCREAMING_SNAKE_CASE is a convention for enum values in GraphQL.

Examples

enum Amenity {
  public_park # snake_case
}

enum Amenity {
  PUBLIC_PARK # SCREAMING_SNAKE_CASE 😱
}

What it does

Checks that enum type names don't start with the prefix Enum.

Rationale

Avoid using the redundant Enum prefix to shorten your schema definitions and improve readability.

Examples

enum EnumResidence {
  HOUSE
  APARTMENT
  CONDO
}

enum Residence {
  HOUSE
  APARTMENT
  CONDO
}

What it does

Checks that enum type names don't use the suffix Enum.

Rationale

Avoid using the redundant Enum suffix to shorten your schema definitions and improve readability.

Examples

enum ResidenceEnum {
  HOUSE
  APARTMENT
  CONDO
}

enum Residence {
  HOUSE
  APARTMENT
  CONDO
}

What it does

If an enum type is used as an input argument, checks that its name uses the suffix Input.

Rationale

Ending input arguments with Input distinguishes inputs from "output" types like objects.

Examples

enum Role {
  EDITOR
  VIEWER
}

type Query {
  users(role: Role): [User!]!
}

enum RoleInput {
  EDITOR
  VIEWER
}

type Query {
  users(role: RoleInput): [User!]!
}

What it does

If an enum is used as the return type of a non-input field, checks that its name doesn't use the suffix Input.

Rationale

Including the suffix Input on an output type is misleading.

Examples

enum RoleInput {
  EDITOR
  VIEWER
}

type Query {
  userRole(userId: ID!): RoleInput
}

enum Role {
  EDITOR
  VIEWER
}

type Query {
  userRole(userId: ID!): Role
}

What it does

Checks that directive names use camelCase.

Rationale

camelCase is a convention for directive names in GraphQL.

Examples

directive @SpecialField on FIELD_DEFINITION # PascalCase

directive @specialField on FIELD_DEFINITION # camelCase

What it does

Checks that an argument of a field or directive definition is present in all subgraphs.

Rationale

The supergraph schema only includes arguments that are exactly the same for all subgraphs that define its field or directive. Learn more.

Examples

type Product {
  id: ID!
  name: String
  price(currency: Currency): Float
}

type Product {
  id: ID!
  name: String
  price(currency: Currency, taxIncluded: Boolean): Float
}

type Product {
  id: ID!
  name: String
  price(currency: Currency, taxIncluded: Boolean): Float
}

type Product {
  id: ID!
  name: String
  price(currency: Currency, taxIncluded: Boolean): Float
}

What it does

Checks that arguments (of a field, input field, or directive definition) have the exact same types in all subgraphs. This warning/error indicates the argument types are compatible but inconsistent.

Rationale

The supergraph schema only includes arguments that are exactly the same for all subgraphs that define its field or directive. Learn more.

Examples

type Product {
  id: ID!
  name: String
  price(currency: Currency!): Float
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price(currency: Currency): Float
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price(currency: Currency!): Float
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price(currency: Currency!): Float
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

What it does

Checks that fields have the exact same types in all subgraphs. This warning/error indicates the field types are compatible but inconsistent.

Rationale

Inconsistent types can lead to discrepancies in the way data is retrieved and processed, resulting in unexpected client behavior.

Examples

type Product {
  id: ID!
  name: String
  price: Money
}

type Money {
  amount: Float!
  currency: Currency!
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price: Money!
}

type Money {
  amount: Float!
  currency: Currency!
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price: Money!
}

type Money {
  amount: Float!
  currency: Currency!
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

type Product {
  id: ID!
  name: String
  price: Money!
}

type Money {
  amount: Float!
  currency: Currency!
}

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

What it does

Checks that argument definitions (of a field, input field, or directive definition) consistently include—or consistently don't include—a default value in all subgraphs that define the argument.

Rationale

Inconsistent defaults can lead to discrepancies in the way data is retrieved and processed, resulting in unexpected client behavior.

Examples

type Product {
  id: ID!
  name: String
  weight(kg: Float = 1.0): Float
}

type Product {
  id: ID!
  name: String
  weight(kg: Float): Float
}

type Product {
  id: ID!
  name: String
  weight(kg: Float = 1.0): Float
}

type Product {
  id: ID!
  name: String
  weight(kg: Float = 1.0): Float
}

What it does

Checks that a type's description is consistent across subgraphs.

Rationale

Inconsistent type descriptions can lead to inconsistent expectations around type values resulting in unexpected client behavior.

Examples

"""
A type representing a product.
"""
type Product {
  id: ID!
  name: String
}

"""
An object representing a product.
"""
type Product {
  id: ID!
  name: String
}

"""
A type representing a product.
"""
type Product {
  id: ID!
  name: String
}

"""
A type representing a product.
"""
type Product {
  id: ID!
  name: String
}

What it does

Checks that an object is consistently declared as an entity (has a @key) in all subgraphs in which the object is defined.

Rationale

If an object is only declared as an entity in some subgraphs, the federated schema won't have complete information about that entity.

Examples

type Product
  @key(fields: "id") {
  id: ID!
  name: String
}

type Product {
  id: ID!
  stock: Int
}

type Product
  @key(fields: "id") {
  id: ID!
  name: String
}

type Product
  @key(fields: "id") {
  id: ID!
  stock: Int
}

What it does

Checks that values of an input enum type are consistently defined in all subgraphs that declare the enum.

Rationale

When a value of an enum that is only used as an input type is defined in only some of the subgraphs that declare the enum, inconsistent values won't be merged into the supergraph. Learn more.

Examples

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER
}

input ProductInput {
  name: String!
  status: ProductStatus!
}

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
}

input ProductInput {
  name: String!
  status: ProductStatus!
}

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER
}

input ProductInput {
  name: String!
  status: ProductStatus!
}

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER
}

input ProductInput {
  name: String!
  status: ProductStatus!
}

What it does

Checks that values of an output enum type are consistently defined in all subgraphs that declare the enum.

Rationale

When values of an output or unused enum type definition are inconsistent, all values are merged into the supergraph. Regardless, it can be helpful to set expectations by including all possible values in all subgraphs defining the enum. Learn more.

Examples

enum OrderStatus {
  CREATED
  PROCESSING
  COMPLETED
}

type Order {
  name: String!
  status: OrderStatus!
}

enum OrderStatus {
  CREATED
  COMPLETED
}

type Order {
  name: String!
  status: OrderStatus!
}

enum OrderStatus {
  CREATED
  PROCESSING
  COMPLETED
}

type Order {
  name: String!
  status: OrderStatus!
}

enum OrderStatus {
  CREATED
  PROCESSING
  COMPLETED
}

type Order {
  name: String!
  status: OrderStatus!
}

What it does

Checks that an executable directive definition is declared with consistent locations across all subgraphs.

Rationale

An executable directive is composed into the supergraph schema only when it is defined identically in all subgraphs. Learn more.

Examples

directive @log(message: String!) on QUERY

directive @log(message: String!) on FIELD

directive @log(message: String!) on QUERY | FIELD

directive @log(message: String!) on QUERY | FIELD

What it does

Checks that an executable directive definition is declared in all subgraphs.

Rationale

An executable directive is composed into the supergraph schema only if it's defined in all subgraphs. Learn more.

Examples

directive @modify(field: String!) on FIELD

# 🦗🦗🦗

directive @modify(field: String!) on FIELD

directive @modify(field: String!) on FIELD

What it does

Checks that an executable directive definition is marked repeatable in all subgraphs that define it.

Rationale

Unless an executable directive is defined as repeatable in all subgraphs, it won't be repeatable in the supergraph.

Examples

directive @validateLength(max: Int!) repeatable on FIELD

directive @validateLength(max: Int!) on FIELD

directive @validateLength(max: Int!) repeatable on FIELD

directive @validateLength(max: Int!) repeatable on FIELD

What it does

Checks that a field of an input object definition is defined in all the subgraphs that declare the input object.

Rationale

The supergraph schema includes only the input object fields that all subgraphs define for the object. Learn more.

Examples

input ProductInput {
  name: String
  price: Float
}

input OrderInput {
  product: ProductInput
}

input ProductInput {
  name: String
}

input OrderInput {
  product: ProductInput
}

input ProductInput {
  name: String
  price: Float
}

input OrderInput {
  product: ProductInput
}

input ProductInput {
  name: String
  price: Float
}

input OrderInput {
  product: ProductInput
}

What it does

Checks that a field of an interface value type (has no @key in any subgraph) is defined in all the subgraphs that declare the type.

Rationale

If different subgraphs contribute different fields to an interface type, any object types that implement that interface must define all contributed fields from all subgraphs. Otherwise, composition fails. Learn more.

Examples

interface Product {
  id: ID!
  name: String
  cost: Float
}

type DigitalProduct implements Product {
  id: ID!
  name: String
  cost: Float
  size: Int
}

interface Product {
  id: ID!
  name: String
  # cost is not defined in the interface
}

type PhysicalProduct implements Product {
  id: ID!
  name: String
  cost: Float
  weight: Float
}

interface Product {
  id: ID!
  name: String
  cost: Float
}

type DigitalProduct implements Product {
  id: ID!
  name: String
  cost: Float
  size: Int
}

interface Product {
  id: ID!
  name: String
  cost: Float
}

type PhysicalProduct implements Product {
  id: ID!
  name: String
  cost: Float
  weight: Float
}

What it does

Checks if a non-repeatable directive is applied to a schema element across different subgraphs with differing arguments.

Rationale

Inconsistent directive argument usage can lead to misunderstandings and potential issues in client applications.

Examples

type Product {
  id: ID!
  name: String
}

type Query {
  allProducts: [Product] @customDirective(orderBy: "name")
}

type Product {
  id: ID!
  name: String
}

type Query {
  allProducts: [Product] @customDirective(orderBy: "price")
}

type Product {
  id: ID!
  name: String
}

type Query {
  allProducts: [Product] @customDirective(orderBy: "name")
}

type Product {
  id: ID!
  name: String
}

type Query {
  allProducts: [Product] @customDirective(orderBy: "name")
}

What it does

Checks that object value types (has no @key in any subgraph) declare the same fields in all subgraphs that declare the type.

Rationale

When an object value type includes differing fields across subgraphs, the supergraph schema includes the union of all fields. Depending on which subgraph executes the query, omitted fields may be unresolvable. You can include the same types as shown below or check out Solutions for unresolvable fields.

Examples

type Product {
  id: ID! @shareable
  name: String @shareable
  price: Float
}

type Product {
  id: ID! @shareable
  name: String @shareable
}

type Product @shareable {
  id: ID!
  name: String
  price: Float
}

type Product @shareable {
  id: ID!
  name: String
  price: Float
}

What it does

Checks that a @shareable field returns consistent sets of runtime types in all subgraphs in which it's defined.

Rationale

Each subgraph's resolver for a @shareable field should behave identically. Otherwise, requests might return inconsistent results depending on which subgraph resolves the field. Learn more.

Examples

type Product {
  id: ID!
  name: String
  details: Details @shareable
}

type Details {
  size: String
}

type Product {
  id: ID!
  name: String
  details: Details @shareable
}

type Details {
  weight: Float
}

type Product {
  id: ID!
  name: String
  details: Details @shareable
}

type Details {
  size: String
}

type Product {
  id: ID!
  name: String
  details: Details @shareable
}

type Details {
  size: String
}

What it does

Checks that a type system directive definition is declared with consistent locations across subgraphs.

Rationale

To ensure consistent expectations, it's best that all definitions declare the same locations. Learn more.

Examples

directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION

directive @customDirective(message: String!) on FIELD_DEFINITION

directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION

directive @customDirective(message: String!) on OBJECT | FIELD_DEFINITION

What it does

Checks that a type system directive definition is marked repeatable in all subgraphs that declare the directive and will be repeatable in the supergraph.

Rationale

To ensure consistent expectations, directives should have consistent definitions across subgraphs, including whether they are repeatable. Learn more.

Examples

directive @customDirective on OBJECT

directive @customDirective repeatable on OBJECT

directive @customDirective repeatable on OBJECT

directive @customDirective repeatable on OBJECT

What it does

Checks that a member of a union definition is defined in all subgraphs that declare the union.

Rationale

When a union definition has inconsistent members, the supergraph schema includes all members in the union definition. Nevertheless, to ensure consistent expectations, it's best that all union definitions declare the same members across subgraphs. Learn more.

Examples

type Product {
  id: ID!
  name: String
}

type Service {
  id: ID!
  description: String
}

union SearchResult = Product | Service

type Product {
  id: ID!
  name: String
}

union SearchResult = Product

type Product {
  id: ID!
  name: String
}

type Service {
  id: ID!
  description: String
}

union SearchResult = Product | Service

type Product {
  id: ID!
  name: String
}

type Service {
  id: ID!
  description: String
}

union SearchResult = Product | Service

What it does

Checks that a field with the @override directive no longer exists in a source subgraph.

Rationale

If a field with the @override directive no longer exists in a source subgraph, the directive can be safely removed.

Examples

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Subgraph B")
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
}

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
}

What it does

Checks if a field has been overridden by another subgraph.

Rationale

You should consider removing overridden fields to avoid confusion.

Examples

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Subgraph B")
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
}

What it does

Checks if a field migration is in progress.

Rationale

You should complete a field migration.

Examples

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Subgraph B", label: "percent(50)")
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
  inStock: Boolean!
}

type Product @key(fields: "id") {
  id: ID!
  name: String!
}

What it does

Checks if an enum type is defined but no field or argument in any subgraph references it.

Rationale

If the enum is defined, it should be used or removed.

Examples

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
}

type Product {
  id: ID!
  name: String
}

type Order {
  id: ID!
  product: Product
  status: String
}

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
}

type Product {
  id: ID!
  name: String
  status: ProductStatus
}

type Order {
  id: ID!
  product: Product
  status: ProductStatus
}

What it does

Checks for issues when composing custom directives.

What it does

Checks if a non-repeatable directive has been applied to the same schema element in different subgraphs with different arguments. Learn more.

Rationale

Arguments should be consistent across a non-repeatable directive's usage. If arguments differ, it may be a sign that subgraph owners need to communicate about the directive's usage. If the arguments need to differ, consider using a repeatable directive.

Examples

type Product {
  id: ID!
  name: String
}

type Query {
  products: [Product] @customDirective(orderBy: ["name"])
}

type Product {
  id: ID!
  name: String
}

type Query {
  products: [Product] @customDirective(orderBy: ["price"])
}

type Product {
  id: ID!
  name: String
}

type Query {
  products: [Product] @customDirective(orderBy: ["name", "price"])
}

type Product {
  id: ID!
  name: String
}

type Query {
  products: [Product] @customDirective(orderBy: ["name", "price"])
}

What it does

Checks for executable directive definitions with no shared locations across subgraphs.

Rationale

Directives must only be used in the locations they are declared to belong in. If the same executable directive is defined with different locations in different subgraphs, it may be a sign that subgraph owners need to communicate about the directive's usage.

Examples

directive @log(message: String!) on QUERY

directive @log(message: String!) on FIELD

directive @log(message: String!) on QUERY | FIELD

directive @log(message: String!) on QUERY | FIELD

What it does

Checks that the source subgraph specified by @override directive exists.

Rationale

The @override directive indicates that an object field is now resolved by a different subgraph. The directive can't work unless you specify an existing subgraph to resolve the field from.

Examples

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Subgraph B")
}

# Subgraph B doesn't exist

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean! @override(from: "Subgraph B")
}

type Product @key(fields: "id") {
  id: ID!
  inStock: Boolean!
}

What it does

Checks for malformed GraphQL schemas. To resolve, check your schema for syntax errors.

What it does

Checks that each element in the schema includes a description.

Rationale

Descriptions document your GraphQL schema so consumers of your graph can easily discover fields and learn how to use them. See examples.

Examples

type User {
  username: String!
}

"Represents a user"
type User {
 "A username must be [8-64] characters."
 username: String!
}

What it does

Checks that every type defined in a schema is used at least once.

Rationale

Unused types waste resources and should be immediately removed once they've been refactored out of a schema.

Examples

type SomeUnusedType { # Also fails the TYPE_SUFFIX rule!
  name: String!
}

type AnActuallyUsedType {
  name: String!
}

type Query {
  hello: String!
  title: AnActuallyUsedType
}

type Book {
  title: String!
}

type Query {
  books: [Book!]!
}

What it does

Checks that schemas don't define operations, such as queries and mutations.

Rationale

Operations should be defined on the client side, not within schemas. Schemas define types, fields, and their relationships. Operations specify what data to fetch or change. Since what to fetch or change is a client concern, this separation allows for a clean and modular architecture, making it easier to manage and evolve the API over time.

Examples

type Query {
  users: [User!]!
}

query GetUsers {
  # Don't define operations in a schema document
  users {
    id
  }
}

What it does

Checks that subgraph schemas always provide owner contact details via the @contact directive.

Rationale

You can use the @contact directive to add your team's contact info to a subgraph schema. This info is displayed in GraphOS Studio, which helps other teams know who to contact for assistance with the subgraph. Learn more.

Examples

"Annotate a schema with contact information for the subgraph owner"
directive @contact(
  "Contact title of the subgraph owner"
  name: String!
  "URL where the subgraph's owner can be reached"
  url: String
  "Other relevant notes can be included here; supports markdown links"
  description: String
) on SCHEMA

extend schema
  @contact(
    name: "Products Team"
    url: "https://myteam.slack.com/archives/teams-chat-room-url"
    description: "Send urgent issues to [#oncall](https://yourteam.slack.com/archives/oncall)."
  )

What it does

Checks that the @deprecated directive always includes a reason argument.

Rationale

The reason argument can help graph consumers understand which field to use instead of the @deprecated one.

Examples

type Product {
  title: String @deprecated
  name: String!
}

type Product {
  title: String @deprecated(reason: "Use Product.name instead")
  name: String!
}

What it does

Checks that the @tag directive uses an approved value for its name argument. You specify approved values in GraphOS Studio.

Rationale

This directive is used most commonly with GraphOS contracts. Validating @tag names ensures contracts work as intended.