Schema linter rules

Reference

This reference lists the rules that you can enforce with GraphOS schema linting, along with the code that GraphOS 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

`FIELD_NAMES_SHOULD_BE_CAMEL_CASE`

Field names should always use camelCase.

❌

schema.graphql

1
type User {
2
  FirstName: String! # PascalCase
3
}

✅

schema.graphql

1
type User {
2
  firstName: String # camelCase
3
}

`RESTY_FIELD_NAMES`

A field's name should never start with any of the following verbs:

get
list
post
put
patch

Most fields should not start with any verb, with the exception of Mutation fields. For Mutation fields, use a verb that more specifically describes the action being performed (such as create, delete, or edit).

❌

schema.graphql

1
type Query {
2
  getUsers: [User!]! 
3
}

✅

schema.graphql

1
type Query {
2
  users: [User!]! 
3
}

Types

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

Objects
Interfaces
Inputs
Enums
Unions

`TYPE_NAMES_SHOULD_BE_PASCAL_CASE`

All type names should use PascalCase.

❌

schema.graphql

1
type streamingService { # camelCase
2
  id: ID!
3
}

✅

schema.graphql

1
type StreamingService { # PascalCase
2
  id: ID!
3
}

`TYPE_PREFIX`

Type names should never use the prefix Type.

❌

schema.graphql

1
type TypeBook { 
2
  title: String!
3
}

✅

schema.graphql

1
type Book { 
2
  title: String!
3
}

`TYPE_SUFFIX`

Type names should never use the suffix Type.

❌

schema.graphql

1
type BookType { 
2
  title: String!
3
}

✅

schema.graphql

1
type Book { 
2
  title: String!
3
}

Objects

`OBJECT_PREFIX`

An object type's name should never use the prefix Object.

❌

schema.graphql

1
type ObjectBook { 
2
  title: String!
3
}

✅

schema.graphql

1
type Book { 
2
  title: String!
3
}

`OBJECT_SUFFIX`

An object type's name should never use the suffix Object.

❌

schema.graphql

1
type BookObject { 
2
  title: String!
3
}

✅

schema.graphql

1
type Book { 
2
  title: String!
3
}

Interfaces

`INTERFACE_PREFIX`

An interface type's name should never use the prefix Interface.

❌

schema.graphql

1
interface InterfaceBook { 
2
  title: String
3
  author: String
4
}

✅

schema.graphql

1
interface Book { 
2
  title: String
3
  author: String
4
}

`INTERFACE_SUFFIX`

An interface type's name should never use the suffix Interface.

❌

schema.graphql

1
interface BookInterface { 
2
  title: String
3
  author: String
4
}

✅

schema.graphql

1
interface Book { 
2
  title: String
3
  author: String
4
}

Inputs & arguments

`INPUT_ARGUMENT_NAMES_SHOULD_BE_CAMEL_CASE`

A GraphQL argument's name should always use camelCase.

❌

schema.graphql

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

✅

schema.graphql

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

`INPUT_TYPE_SUFFIX`

An input type's name should always use the suffix Input.

❌

schema.graphql

1
input BlogPostDetails { 
2
  title: String!
3
  content: String!
4
}

✅

schema.graphql

1
input BlogPostDetailsInput { 
2
  title: String!
3
  content: String!
4
}

Enums

`ENUM_VALUES_SHOULD_BE_SCREAMING_SNAKE_CASE`

Enum values should always use SCREAMING_SNAKE_CASE.

❌

schema.graphql

1
enum Amenity {
2
  public_park # snake_case
3
}

✅

schema.graphql

1
enum Amenity {
2
  PUBLIC_PARK # SCREAMING_SNAKE_CASE 😱
3
}

`ENUM_PREFIX`

An enum type's name should never use the prefix Enum.

❌

schema.graphql

1
enum EnumResidence { 
2
  HOUSE
3
  APARTMENT
4
  CONDO
5
}

✅

schema.graphql

1
enum Residence { 
2
  HOUSE
3
  APARTMENT
4
  CONDO
5
}

`ENUM_SUFFIX`

An enum type's name should never use the suffix Enum.

❌

schema.graphql

1
enum ResidenceEnum { 
2
  HOUSE
3
  APARTMENT
4
  CONDO
5
}

✅

schema.graphql

1
enum Residence { 
2
  HOUSE
3
  APARTMENT
4
  CONDO
5
}

`ENUM_USED_AS_INPUT_WITHOUT_SUFFIX`

If an enum type is used as an input argument, its name should use the suffix Input.

❌

schema.graphql

1
enum Role { 
2
  EDITOR
3
  VIEWER
4
}
5

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

✅

schema.graphql

1
enum RoleInput { 
2
  EDITOR
3
  VIEWER
4
}
5

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

`ENUM_USED_AS_OUTPUT_DESPITE_SUFFIX`

If an enum is used as the return type of a non-input field, its name should not use the suffix Input.

❌

schema.graphql

1
enum RoleInput { 
2
  EDITOR
3
  VIEWER
4
}
5

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

✅

schema.graphql

1
enum Role { 
2
  EDITOR
3
  VIEWER
4
}
5

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

Directives

`DIRECTIVE_NAMES_SHOULD_BE_CAMEL_CASE`

Directive names should always use camelCase.

❌

schema.graphql

1
directive @SpecialField on FIELD_DEFINITION # PascalCase

✅

schema.graphql

1
directive @specialField on FIELD_DEFINITION # camelCase

Composition rules
Since 2.4

ⓘ NOTE

Composition rules are only available for graphs on federation version 2.4 or later. You can update a graph's version from its Settings page in GraphOS Studio.

These rules flag potential improvements to a supergraph schema composed of subgraph schemas.

Inconsistent elements

`INCONSISTENT_ARGUMENT_PRESENCE`

Indicates that an optional argument (of a field or directive definition) isn't present in all subgraphs and therefore won't be part of the supergraph.

❌

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
  price(currency: Currency): Float 
5
}

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
  price(currency: Currency, taxIncluded: Boolean): Float 
5
}

✅

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
  price(currency: Currency, taxIncluded: Boolean): Float 
5
}

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
  price(currency: Currency, taxIncluded: Boolean): Float 
5
}

`INCONSISTENT_BUT_COMPATIBLE_ARGUMENT_TYPE`

Indicates that an argument type (of a field, input field, or directive definition) doesn't have the exact same type in all subgraphs, but that the types are compatible.

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.

❌

Subgraph A

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

Subgraph B

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

✅

Subgraph A

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

Subgraph B

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

`INCONSISTENT_BUT_COMPATIBLE_FIELD_TYPE`

Indicates that a field doesn't have the exact same types in all subgraphs, but that the types are compatible.

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.

❌

Subgraph A

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

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

Subgraph B

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

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

✅

Subgraph A

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

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

Subgraph B

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

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

enum Currency {
  USD
  EUR
  GBP
  JPY
  AUD
  CAD
}

`INCONSISTENT_DEFAULT_VALUE_PRESENCE`

Indicates that an argument definition (of a field, input field, or directive definition) has a default value in only some of the subgraphs that define the argument.

❌

Subgraph A

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

Subgraph B

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

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_DESCRIPTION`

Indicates that an element has a description in more than one subgraph, and the descriptions aren't equal.

❌

Subgraph A

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

Subgraph B

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

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_ENTITY`

Indicates that an object is declared as an entity (has a @key) in only some of the subgraphs in which the object is defined.

❌

Subgraph A

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

Subgraph B

type Product { 
  id: ID!
  stock: Int
}

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_ENUM_VALUE_FOR_INPUT_ENUM`

Indicates that a value of an enum type definition, that is only used as an input type, hasn't been merged into the supergraph because it's defined in only some of the subgraphs that declare the enum.

❌

Subgraph A

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER 
}

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

Subgraph B

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
}

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

✅

Subgraph A

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER
}

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

Subgraph B

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
  BACK_ORDER
}

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

`INCONSISTENT_ENUM_VALUE_FOR_OUTPUT_ENUM`

Indicates that a value of an enum type definition, that is only used as an output type or is unused, has been merged in the supergraph but is defined in only some of the subgraphs that declare the enum.

❌

Subgraph A

enum OrderStatus {
  CREATED
  PROCESSING 
  COMPLETED
}

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

Subgraph B

enum OrderStatus {
  CREATED
  COMPLETED
}

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

✅

Subgraph A

enum OrderStatus {
  CREATED
  PROCESSING
  COMPLETED
}

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

Subgraph B

enum OrderStatus {
  CREATED
  PROCESSING
  COMPLETED
}

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

`INCONSISTENT_EXECUTABLE_DIRECTIVE_LOCATIONS`

Indicates that an executable directive definition is declared with inconsistent locations across subgraphs. (The supergraph schema then uses the intersection of all locations in the supergraph.)

❌

Subgraph A

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

Subgraph B

directive @log(
  message: String!
) on FIELD

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_EXECUTABLE_DIRECTIVE_PRESENCE`

Indicates that an executable directive definition is declared in only some of the subgraphs.

❌

Subgraph A

directive @modify(
  field: String!
) on FIELD

Subgraph B

# 🦗🦗🦗

✅

Subgraph A

directive @modify(
  field: String!
) on FIELD

Subgraph B

directive @modify(
  field: String!
) on FIELD

`INCONSISTENT_EXECUTABLE_DIRECTIVE_REPEATABLE`

Indicates that an executable directive definition is marked repeatable in only some of the subgraphs and won't be repeatable in the supergraph.

❌

Subgraph A

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

Subgraph B

directive @validateLength(
  max: Int!
) on FIELD

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_INPUT_OBJECT_FIELD`

Indicates that a field of an input object type definition is only defined in some of the subgraphs that declare the input object.

❌

Subgraph A

input ProductInput {
  name: String
  price: Float 
}

input OrderInput {
  product: ProductInput
}

Subgraph B

input ProductInput {
  name: String
}

input OrderInput {
  product: ProductInput
}

✅

Subgraph A

input ProductInput {
  name: String
  price: Float
}

input OrderInput {
  product: ProductInput
}

Subgraph B

input ProductInput {
  name: String
  price: Float
}

input OrderInput {
  product: ProductInput
}

`INCONSISTENT_INTERFACE_VALUE_TYPE_FIELD`

Indicates that a field of an interface "value type" (has no @key in any subgraph) isn't defined in all the subgraphs that declare the type.

❌

Subgraph A

1
interface Product {
2
  id: ID!
3
  name: String
4
  cost: Float 
5
}
6

7
type DigitalProduct implements Product {
8
  id: ID!
9
  name: String
10
  cost: Float
11
  size: Int 
12
}

Subgraph B

1
interface Product {
2
  id: ID!
3
  name: String
4
  # cost is not defined in the interface
5
}
6

7
type PhysicalProduct implements Product {
8
  id: ID!
9
  name: String
10
  cost: Float
11
  weight: Float 
12
}

✅

Subgraph A

1
interface Product {
2
  id: ID!
3
  name: String
4
  cost: Float 
5
}
6

7
type DigitalProduct implements Product {
8
  id: ID!
9
  name: String
10
  cost: Float
11
  size: Int 
12
}

Subgraph B

1
interface Product {
2
  id: ID!
3
  name: String
4
  cost: Float 
5
}
6

7
type PhysicalProduct implements Product {
8
  id: ID!
9
  name: String
10
  cost: Float
11
  weight: Float 
12
}

`INCONSISTENT_NON_REPEATABLE_DIRECTIVE_ARGUMENTS`

A non-repeatable directive is applied to a schema element in different subgraphs but with arguments that are different.

❌

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

✅

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

`INCONSISTENT_OBJECT_VALUE_TYPE_FIELD`

Indicates that a field of an object "value type" (has no @key in any subgraph) isn't defined in all the subgraphs that declare the type.

❌

Subgraph A

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

Subgraph B

type Product {
  id: ID!
  name: String
}

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_RUNTIME_TYPES_FOR_SHAREABLE_RETURN`

Indicates that a @shareable field returns different sets of runtime types in the different subgraphs in which it's defined.

❌

Subgraph A

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

type Details {
  size: String 
}

Subgraph B

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

type Details {
  weight: Float 
}

✅

Subgraph A

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

type Details {
  size: String 
}

Subgraph B

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

type Details {
  size: String 
}

`INCONSISTENT_TYPE_SYSTEM_DIRECTIVE_LOCATIONS`

Indicates that an executable directive definition is declared with inconsistent locations across subgraphs. (The supergraph schema then uses the intersection of all locations in the supergraph.)

❌

Subgraph A

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

Subgraph B

directive @customDirective(
  message: String!
) on FIELD_DEFINITION

✅

Subgraph A

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

Subgraph B

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

`INCONSISTENT_TYPE_SYSTEM_DIRECTIVE_REPEATABLE`

Indicates that a type system directive definition is marked repeatable in only some of the subgraphs that declare the directive and will be repeatable in the supergraph.

❌

Subgraph A

1
directive @customDirective on OBJECT

Subgraph B

1
directive @customDirective repeatable on OBJECT

✅

Subgraph A

1
directive @customDirective repeatable on OBJECT

Subgraph B

1
directive @customDirective repeatable on OBJECT

`INCONSISTENT_UNION_MEMBER`

Indicates that a member of a union type definition is only defined in some of the subgraphs that declare the union.

❌

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

6
type Service {
7
  id: ID!
8
  description: String
9
}
10

11
union SearchResult = Product | Service

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

6
union SearchResult = Product

✅

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

6
type Service {
7
  id: ID!
8
  description: String
9
}
10

11
union SearchResult = Product | Service

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

6
type Service {
7
  id: ID!
8
  description: String
9
}
10

11
union SearchResult = Product | Service

Overridden and unused elements

`OVERRIDE_DIRECTIVE_CAN_BE_REMOVED`

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

❌

Subgraph A

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

Subgraph B

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

✅

Subgraph A

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

Subgraph B

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

`OVERRIDDEN_FIELD_CAN_BE_REMOVED`

Indicates that a field has been overridden by another subgraph. You should consider removing the overriden field to avoid confusion.

❌

Subgraph A

1
type Product @key(fields: "id") {
2
  id: ID!
3
  name: String!
4
  inStock: Boolean! @override(from: "Subgraph B")
5
}

Subgraph B

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

✅

Subgraph A

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

Subgraph B

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

`UNUSED_ENUM_TYPE`

Indicates that an enum type is defined in some subgraphs but is unused (no field/argument references it). All values from subgraphs defining that enum will be included in the supergraph.

❌

Subgraph A

enum ProductStatus {
  AVAILABLE
  SOLD_OUT
}

type Product {
  id: ID!
  name: String
}

Subgraph B

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

✅

Subgraph A

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

Subgraph B

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

Directives

`DIRECTIVE_COMPOSITION`

Indicates that an issue was detected when composing custom directives.

`MERGED_NON_REPEATABLE_DIRECTIVE_ARGUMENTS`

Indicates a non-repeatable directive has been applied to a schema element in different subgraphs with different arguments and the arguments values were merged using the directive configured strategies.

❌

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

✅

Subgraph A

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

Subgraph B

1
type Product {
2
  id: ID!
3
  name: String
4
}
5

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

`NO_EXECUTABLE_DIRECTIVE_INTERSECTION`

Indicates that an executable directive definition is declared with no shared locations across subgraphs.

❌

Subgraph A

directive @log(
  message: String!
) on QUERY

Subgraph B

directive @log(
  message: String!
) on FIELD

✅

Subgraph A

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

Subgraph B

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

`FROM_SUBGRAPH_DOES_NOT_EXIST`

Indicates the source subgraph specified by @override directive doesn't exist.

❌

Subgraph A

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

Subgraph B

1
# Subgraph B doesn't exist

✅

Subgraph A

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

Subgraph B

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

Other rules

These rules define conventions for the entire schema and directive usage outside of composition.

Schema

These rules apply to the entire schema.

`DOES_NOT_PARSE`

The schema linter raises this violation if it attempts to read a malformed GraphQL schema. Check your schema for any syntax errors.

`ALL_ELEMENTS_REQUIRE_DESCRIPTION`

Each element in the schema must include a description.

❌

schema.graphql

1
type User {
2
  username: String!
3
}

✅

schema.graphql

1
"Represents a user"
2
type User {
3
  "The user's username"
4
  username: String!
5
}

`DEFINED_TYPES_ARE_USED`

Every type defined in a schema should be used at least once.

Unused types commonly appear after you refactor other parts of your schema. You should remove unused types to prevent confusion.

❌

schema.graphql

1
type SomeUnusedType { # Also fails the TYPE_SUFFIX rule!
2
  name: String!
3
}
4

5
type AnActuallyUsedType {
6
  name: String!
7
}
8

9
type Query {
10
  hello: String!
11
  title: AnActuallyUsedType
12
}

✅

schema.graphql

1
type Book {
2
  title: String!
3
}
4

5
type Query {
6
  books: [Book!]!
7
}

`QUERY_DOCUMENT_DECLARATION`

A GraphQL schema should never include definitions of GraphQL operations (such as queries and mutations).

❌

schema.graphql

1
type Query {
2
  users: [User!]!
3
}
4

5
query GetUsers {
6
  # Don't define operations in a schema document
7
  users {
8
    id
9
  }
10
}

Directives

`CONTACT_DIRECTIVE_MISSING`

A subgraph schema should always provide owner contact details via the @contact directive. Learn more.

✅

schema.graphql

1
directive @contact(
2
  "Contact title of the subgraph owner"
3
  name: String!
4
  "URL where the subgraph's owner can be reached"
5
  url: String
6
  "Other relevant notes can be included here; supports markdown links"
7
  description: String
8
) on SCHEMA
9

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

`DEPRECATED_DIRECTIVE_MISSING_REASON`

The @deprecated directive should always include a reason argument.

❌

schema.graphql

1
type Product {
2
  title: String @deprecated 
3
  name: String!
4
}

✅

schema.graphql

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

`TAG_DIRECTIVE_USES_UNKNOWN_NAME`

The @tag directive should always use an approved value for its name argument. You specify approved values in GraphOS Studio.

Overview

Publishing schemas