Allow defining empty types

[vladshcherbin]

Currently this is not possible:

type Mutation {}

extend type Mutation {
  createPermission(input: CreatePermissionInput!): Permission
}

It's needed when you want to split your schema into multiple files. Instead, you need to define at least one field:

type Mutation {
  dummyNotNeededMutationHere(): Smth
}

It would be awesome to be able to define empty types to later extend them.

[cedrelek]

I would be happy to do that too. For now I write :

type Mutation {
  _ : Boolean
}

[vladshcherbin]

I actually found another way that can suit me for now (I'm using graphql-tools):

// user mutations
const UserMutationFields = `
  createUser(input: CreateUserInput!): User
  updateUser(input: UpdateUserInput!): User
  removeUser(input: RemoveUserInput!): User
`

// root mutation
const MutationType = `
  type Mutation {
    ${UserMutationFields}
  }
`

[cedrelek]

Ok Nice. I guess you only need for the root objects (Query, Mutation and Subscription) ?

[vladshcherbin]

@cedrelek yeah, I'm currently using this for root Query and Mutation, but I think it can be used with any type.

[chrisregnier]

I've run into the same problem and have to put in fake fields to my root Query/Mutation type. Since I define all my schemas in separate graphqls files, slicing things up differently as suggested above doesn't work as well for me.
I'd love to clean this up, so has there been any progress here?

[alexisgahon]

Any update on this issue ?
It would be nice to allowing an empty type declaration ... since a type is not really empty (__type and __schema).

[nabiltntn]

Meanwhile, I used this package to merge my schema files ( and resolvers ) and avoid defining fake field https://github.com/okgrow/merge-graphql-schemas

Pros

• You dont have to use extend in your schema defition
• You can define schema in .graphql files and benefit from syntax highlighting

Cons

• Since you dont import explicitly types from others schema files, you have to search manually to find their definition

Do you have experience using this package ?

[leebyron]

The latest updates to the master branch enable this via type Mutation - see https://github.com/graphql/graphql-js/blob/master/src/language/__tests__/schema-kitchen-sink.graphql#L15-L29

Release coming soon

[samuela]

Another case where this is super helpful: When you want to emulate ML-style algebraic data types you're screwed for variants that don't have any fields. For example,

type Mutation {
  createUser(email: String!, password: String!): CreateUserPayload!
}

type UserWithEmailAlreadyExists {}
type WeakPassword {}
type AuthPayload {
  user: User!
  token: AccessToken!
}
union CreateUserPayload = UserWithEmailAlreadyExists | WeakPassword | AuthPayload

[samuela]

Update: this is possible as of "graphql-yoga": "^1.16.7":

type Mutation {
  createUser(email: String!, password: String!): CreateUserPayload!
}

type UserWithEmailAlreadyExists
type WeakPassword
type AuthPayload {
  user: User!
  token: AccessToken!
}
union CreateUserPayload = UserWithEmailAlreadyExists | WeakPassword | AuthPayload

GitHub doesn't syntax highlight it correctly but it does in fact work.

[samuela]

Further update: that actually doesn't work. It parses the schema fine, but after starting the server I'm seeing:

Error: Type UserWithEmailAlreadyExists must define one or more fields.

Type WeakPassword must define one or more fields.
    at assertValidSchema (/Users/skainswo/dev/kumo/newer-world/api/node_modules/graphql/type/validate.js:71:11)
    at Object.validate (/Users/skainswo/dev/kumo/newer-world/api/node_modules/graphql/validation/validate.js:55:35)
    at doRunQuery (/Users/skainswo/dev/kumo/newer-world/api/node_modules/apollo-server-core/src/runQuery.ts:181:30)
    at /Users/skainswo/dev/kumo/newer-world/api/node_modules/apollo-server-core/src/runQuery.ts:80:39
    at process._tickCallback (internal/process/next_tick.js:68:7)

[alamothe]

Hello, I still get this error, and looking at the code the check is still there: https://github.com/graphql/graphql-js/blob/master/src/type/validate.js#L273

Is this resolved or no?

[alamothe]

...For now I solved this by commenting out that check. It looks like everything works afterwards, suggesting that the check is completely arbitrary and a waste of code.

Note also that GraphQL spec allows empty types.

My use case is the same as @samuela

[ProjectFrank]

@alamothe where in the GraphQL spec does it say that empty types are allowed?

Per the working draft:

An Object type must define one or more fields.

[alamothe]

Sorry my bad, it is a problem with the spec.