import { schema } from 'nexus'

Guide ⌁ issues (features | bugs)

The Schema component is designed for building your GraphQL schema. It will undoubtedly be the component you use most in your project. If you are new to this component then you may be interested in our schema guide.

objectType

GraphQL Docs for Object Types

The most common kind of type in most GraphQL schemas. of a GraphQL schema are object types, a type you can fetch from your schema, with fields:

Signature

1objectType(config: {
2 name: string
3 description?: string
4 rootTyping?: NexusGenBackingTypes
5 nonNullDefaults?: NonNullConfig
6 definition: ObjectDefinitionBlock
7}) => NexusObjectType
  • name (required) The name of this object.
  • definition (required) The function used to define the fields of this object. See below for the various field builders available.
  • description The description of this object. Tools like GraphQL Playground can display this content.
  • nonNullDefaults (NonNullConfig)
  • rootTyping (NexusGenBackingTypes)

Example

1import { schema } from 'nexus'
2
3schema.objectType({
4 name: 'User',
5 definition(t) {
6 t.int('id', { description: 'Id of the user' })
7 t.string('fullName', { description: 'Full name of the user' })
8 t.list.field('posts', {
9 type: 'Post',
10 resolve(post, args, ctx) {
11 return ctx.db.user.getOne(post.id).posts()
12 },
13 })
14 },
15})
16
17schema.objectType({
18 name: 'Post',
19 definition(t) {
20 t.int('id')
21 t.string('title')
22 },
23})

t.field

Signature

1(
2 name: string,
3 config: FieldConfig
4) => void

🚧 Work in progress.

t.<scalar>

1t.id
2t.string
3t.boolean
4t.int
5t.float

Field builder specialization for GraphQL scalar types: string, boolean, int, float, id. They are like t.field but omit the config.type property and accept a resolver as their second parameter as an alternative to full-on field config.

Signature

1(name: string, param?: UntypedFieldConfig | Resolver) => void

t.list

Use this to express a list of some other type. All field builders are available as properties.

t.implements

🚧 Work in progress.

Signature

1(...interfaceNames: string[]) => void

t.modify

Modify a field added via an interface.

Signature

1(fieldName: string, modifications: 🚧 Work in progress.) => void

🚧 Work in progress.

t.connection

This field builder helps you implement paginated associations between types in your schema. The contributions that it makes to your GraphQL schema adhere to the Relay Connection Specification. In other words it allows you the API author to write the minimum logic required to create spec-compliant relay connections for your API clients.

Signature

1(
2 fieldName: string,
3 config: {
4 type: GraphQLType,
5 additionalArgs?: Args
6 inheritAdditionalArgs?: boolean
7 disableForwardPagination?: boolean
8 disableBackwardPagination?: boolean
9 strictArgs?: boolean
10 validateArgs?: (
11 argsArgs: Args,
12 info: ResolverInfo
13 ) => void
14 extendConnection?: (t: TypeBuilder) => void
15 extendEdge?: (t: TypeBuilder) => void
16 pageInfoFromNodes?: (
17 nodes: Node[],
18 args: Args,
19 context: Context,
20 info: ResolverInfo
21 ) => {
22 hasNextPage: boolean,
23 hasPreviousPage: boolean
24 }
25 cursorFromNode?: (
26 node: Node,
27 args: Args,
28 context: Context,
29 info: ResolverInfo,
30 forCursor: {
31 index: number
32 nodes: Node[]
33 }
34 ) => MaybePromise<string>
35 } &
36 | { nodes?: never, resolve: Resolver }
37 | { resolve?: never, nodes: NodeResolver }
38) => void

param config

  • type (GraphQLType) The type of this field.

  • resolve (Resolver) Implement everything yourself.

    • Useful for more complex pagination cases, where you may want to use utilities from other libraries like graphql-relay, and only use Nexus for the construction and type-safety.
    • Unlike with nodes approach, this approach makes no assumptions about values for the edges cursor pageInfo properties.
Optionality

Forbidden if nodes given. Required otherwise.

nodes (NodeResolver)

Optionality

Forbidden if resolve given. Required otherwise.

Remarks

When you use this approach (instead of resolve), Nexus makes some assumptions about the structure of the connection. You are only required to return a list of nodes to resolve based on the connection, and then we will automatically infer the hasNextPage, hasPreviousPage, and cursor values for you.

The returned array of nodes should have a length of one greater than the requested item count. The additional item should be placed according to this pattern:

  • paginating forward / selecting first: last
  • paginating backward / selecting last: first

For example, if the query is paginating forward, and there are 20 nodes in the returned array:

1Query Args Returned Nodes
2
3(first: 2) [{id: 1}, {id: 2}, {id: 3}]
4 ~~~~~~~ ------------------- Extra
5(last: 2) [{id: 18}, {id: 19}, {id: 20}]
6 ~~~~~~~~ ------------------------------------- Extra

Nexus then slices the array in the paginating direction, and if there are more than "N" node results, Nexus takes this to mean that there is another page in the paginating direction.

If you set assumeExactNodeCount to true in schema.connections setting then this heuristic changes. Nexus then assumes that a next page exists if the returned array length is >= to requested node count.

additionalArgs (Args)

Additional arguments to use for just this field.

Default

undefined

Remarks

When used, the additionalArgs in app settings schema.connections will not be inherited. If you do wish to inherit them, enable that with inheritAdditionalArgs.

inheritAdditionalArgs

Whether to inherit the additionalArgs from app settings schema.connections

Default

true if additionalArgs is not set, false otherwise.

disableForwardPagination

If true then first and after args are not present. When disabled, last arg becomes required, unless you disable strictArgs.

Default

false

disableBackwardPagination

If true then last and before args are not present. When disabled, first arg becomes required, unless you disable strictArgs.

Default

false

strictArgs

Whether first/last arg nullability should reflect the forward/backward pagination configuration. When true, then the following pattern is used:

  • when only forward pagination enabled
    • meaning, disableForwardPagination && !disableBackwardPagination
    • then, last arg is required
  • when only backward pagination enabled
    • meaning, !disableForwardPagination && disableBackwardPagination
    • then, first arg is required
Default

true

validateArgs

Custom logic to validate the args. Throw an error to signal validation failure.

Signature
1(args: Args, info: ResolverInfo) => void
Default

Validates that client passes a first or a last arg, and not both.

extendConnection

Dynamically add additional fields to the GraphQL connection object. Similar to extendEdge.

Signature
1(t: TypeBuilder) => void
Default

undefined

Remarks

Because this customizes the GraphQL connection object type, the name of the type will necessarily be changed as well. If it didn't, it would conflict with the non-extended connection type in your schema (if any). The following pattern will be used to name the GraphQL object type:

1{camelCaseJoin: <typeName><fieldName>}_Connection
Example
1schema.queryType({
2 name: 'Query',
3 definition(t) {
4 t.connection("toto", {
5 type: 'Boolean',
6 extendConnection(t) {
7 t.string('foo', () => 'bar')
8 }
9 }),
10 ...
11 }
12})
1type QueryToto_Connection {
2 edges: [BooleanEdge]
3 pageInfo: PageInfo!
4 foo: String!
5}
6...

extendEdge

Dynamically add additional fields to the GraphQL edge object. Similar to extendConnection.

Signature
1(t: TypeBuilder) => void
Default

undefined

Remarks

Because this customizes the GraphQL edge object type, the name of the type will necessarily be changed as well. If it didn't, it would conflict with the non-extended edge type in your schema (if any). The following pattern will be used to name the GraphQL object type:

1{camelCaseJoin: <typeName><fieldName>}_Edge
Example
1schema.queryType({
2 name: 'Query',
3 definition(t) {
4 t.connection("toto", {
5 type: 'Boolean',
6 extendEdge(t) {
7 t.string('foo', () => 'bar')
8 }
9 }),
10 ...
11 }
12})
1type QueryToto_Edge {
2 cursor: String!
3 node: Boolean!
4 foo: String!
5}
6...

pageInfoFromNodes

Override the default algorithm to determine hasNextPage and hasPreviousPage page info fields. Often needed when using cursorFromNode. See nodes for what default algorithm is.

Signature
1(
2 nodes: Node[],
3 args: Args,
4 context: Context,
5 info: ResolverInfo
6) => {
7 hasNextPage: boolean,
8 hasPreviousPage: boolean
9}
Default

undefined

cursorFromNode

Approach we use to transform a node into a cursor.

Signature
1(
2 node: Node,
3 args: Args,
4 context: Context,
5 info: ResolverInfo,
6 forCursor: {
7 index: number
8 nodes: Node[]
9 }
10) => MaybePromise<string>
Default

'nodeField'

SchemaContributions

🚧 Work in progress.

Example of using resolve

1import { schema } from 'nexus'
2import { connectionFromArray } from 'graphql-relay'
3
4schema.queryType({
5 definition(t) {
6 t.connection('users', {
7 type: 'User',
8 async resolve(root, args, ctx, info) {
9 return connectionFromArray(await ctx.resolveUserNodes(), args)
10 },
11 })
12 },
13})

Example of using nodes

1schema.queryType({
2 definition(t) {
3 t.connection('users', {
4 type: 'User',
5 nodes(root, args, ctx, info) {
6 // [{ id: 1, ... }, ..., { id: 10, ... }]
7 return ctx.users.resolveForConnection(root, args, ctx, info)
8 },
9 })
10 },
11})

One limitation of the nodes property, is that you cannot paginate backward without a cursor, or without defining a cursorFromNode property on either the field or plugin config. This is because we can't know how long the connection list may be to begin paginating backward.

1schema.queryType({
2 definition(t) {
3 t.connection('usersConnectionNodes', {
4 type: 'User',
5 cursorFromNode(node, args, ctx, info, { index, nodes }) {
6 if (args.last && !args.before) {
7 const totalCount = USERS_DATA.length
8 return `cursor:${totalCount - args.last! + index + 1}`
9 }
10 return connectionPlugin.defaultCursorFromNode(node, args, ctx, info, {
11 index,
12 nodes,
13 })
14 },
15 nodes() {
16 // ...
17 },
18 })
19 },
20})

Example of using additionalArgs

1schema.queryType({
2 definition(t) {
3 t.connection('userConnectionAdditionalArgs', {
4 type: 'User',
5 disableBackwardPagination: true,
6 additionalArgs: {
7 isEven: schema.booleanArg({
8 description: 'If true, filters the users with an odd pk',
9 }),
10 },
11 resolve() {
12 // ...
13 },
14 })
15 },
16})

Example of extending connection type globally

1settings.change({
2 schema: {
3 connections: {
4 extendConnection: {
5 totalCount: {
6 type: 'Int',
7 },
8 },
9 },
10 },
11})
12
13schema.queryType({
14 definition(t) {
15 t.connection('users', {
16 type: 'User',
17 nodes() {
18 // ...
19 },
20 totalCount() {
21 return ctx.users.totalCount(args)
22 },
23 })
24 },
25})

Example of extending connection type for one field

1schema.queryType({
2 definition(t) {
3 t.connection('users', {
4 extendConnection(t) {
5 t.int('totalCount', {
6 resolve(source, args, ctx) {
7 return ctx.users.totalCount(args),
8 }
9 })
10 },
11 })
12 },
13})

queryType

Refer to objectType. This is a shorthand where config.name is assigned Query.

mutationType

Refer to objectType. This is a shorthand where config.name is assigned Mutation.

subscriptionType

GraphQL Spec

Similar to objectType. However, there are a few differences with regard to field configuration. Here is an overview. For details see below.

1schema.subscriptionType({
2 // rootTyping // There is no rootTyping configuration
3 definition(t) {
4 t.field({ // This and all other field builders...
5 subscribe() {} // ... uniquely have a subscribe method
6 resolve(event) {} // ... have an adjustment to the Backing type
7 })
8 }
9})

Signature

1(config: {
2 definition: SubscriptionDefinitionBlock
3 description?: string
4 nonNullDefaults?: NonNullConfig
5}) => NexusInputObjectType

Field Configuration

Extends field configurations of those found in objectType like so:

1subscribe(root, args, ctx, info): MaybePromise<AsyncIterator<...>>
2resolve(event, args, ctx, info): MaybePromise<...>
  • subscribe Called once when the initial subscription request is sent by the client. It must return an AsyncIterator. The values emitted via it flow into the peer method resolve. The point of this method is to setup the data link between your streaming data source and a client subscription. It is not concerned with shaping the data coming off the streaming data source into something comforming to the GraphQL type assigned to the field. that is the job of the peer method resolve.

  • resolve Called for every value emitted by the AsyncIterator returned by subscribe. The value is the first argument to resolve, replacing the backing data parameter that is usuaully passed there. The point of this method is to receive the raw event data from your data source and make it conform to the GraphQL type assigned to the field––just like all resolvers do. The only difference is that the backing data aspect.

inputObjectType

GraphQL Docs for Input Object Types

Defines an object which can be passed as an input value.

Signature

1(config: {
2 name: string
3 definition: InputObjectDefinitionBlock
4 description?: string
5 nonNullDefaults?: NonNullConfig
6}) => NexusInputObjectType

name

The name of this object.

description

The description of this object. Tools like GraphQL Playground can display this content.

Default

undefined

nonNullDefaults

🚧 Work in progress.

Default

undefined

definition

See below for the various field builders available.

Example

1import { schema } from 'nexus'
2
3schema.inputObjectType({
4 name: 'MyInput',
5 definition(t) {
6 t.string('foo', { required: true })
7 t.int('bar')
8 },
9})
10
11schema.objectType({
12 name: 'Qux',
13 definition(t) {
14 t.string('toto', {
15 args: {
16 myInput: 'MyInput',
17 },
18 })
19 },
20})
1input MyInput {
2 bar: Int
3 foo: String!
4}
5
6type Qux {
7 toto(myInput: MyInput): String
8}

Unlike object types, input types do not have arguments, so they do not have resolvers or "backing types"

t.field

🚧 Work in progress.

t.<scalar>

🚧 Work in progress.

t.list

🚧 Work in progress.

enumType

GraphQL Docs for Enum Types

Signature

1enumType(config: NexusEnumTypeConfig): NexusEnumTypeDef

NexusEnumTypeConfig options

  • name (required): Name of your type
  • members (required): All members of the enum, either as an array of strings/definition objects, as an object, or as a TypeScript enum
  • description (optional): The description to annotate the GraphQL SDL
  • rootTyping (optional): Root type information for this type. By default, types are extracted for any .ts file in your project. You can configure that from the schema.rootTypingsGlobPattern setting

Example

Defining as an array of enum values:

1import { schema } from 'nexus'
2
3const Episode = schema.enumType({
4 name: 'Episode',
5 members: ['NEWHOPE', 'EMPIRE', 'JEDI'],
6 description: 'The first Star Wars episodes released',
7})

As an object, with a simple mapping of enum values to internal values:

1import { schema } from 'nexus'
2
3const Episode = schema.enumType({
4 name: 'Episode',
5 members: {
6 NEWHOPE: 4,
7 EMPIRE: 5,
8 JEDI: 6,
9 },
10})

interfaceType

GraphQL Docs for Interface Types

In Nexus, you do not need to redefine the interface fields on the implementing object types, instead you may use .implements(interfaceName) and all of the interface fields will be added to the type.

Signature

1interfaceType(config: NexusInterfaceTypeConfig): NexusInterfaceTypeDef

NexusInterfaceTypeConfig options

  • name (required): Name of your type
  • definition (required): A function to define the fields of your type
  • description (optional): The description to annotate the GraphQL SDL
  • nonNullDefaults (optional): Configures the nullability for the type, check the documentation's "Getting Started" section to learn more about GraphQL Nexus's assumptions and configuration on nullability.
  • rootTyping (optional): Root type information for this type. By default, types are extracted for any .ts file in your project. You can configure that from the schema.rootTypingsGlobPattern setting

Example

1import { schema } from 'nexus'
2
3schema.interfaceType({
4 name: 'Node',
5 definition(t) {
6 t.id('id', { description: 'GUID for a resource' })
7 },
8})
9
10schema.objectType({
11 name: 'User',
12 definition(t) {
13 t.implements('Node')
14 },
15})

If you need to modify the description or resolver defined by an interface, you can call the modify method on objectType to change these after the fact.

scalarType

GraphQL Docs for Scalar Types

Nexus allows you to provide an asNexusMethod property which will make the scalar available as a builtin on the definition block object. We automatically generate and merge the types so you get type-safety just like the scalar types specified in the spec.

Signature

1scalarType(config: NexusScalarTypeConfig): NexusScalarTypeDef

NexusScalarTypeConfig options

  • name (required): Name of your type
  • serialize (required): Serializes an internal value to include in a response
  • description (optional): The description to annotate the GraphQL SDL
  • deprecation (optional): Any deprecation info for this scalar type
  • parseValue (optional): Parses an externally provided value to use as an input
  • parseLiteral (optional): Parses an externally provided literal value to use as an input
  • asNexusMethod (optional): Adds this type as a method on the Object/Interface definition blocks
  • rootTyping (optional): Root type information for this type. By default, types are extracted for any .ts file in your project. You can configure that from the schema.rootTypingsGlobPattern setting

Example

1import { schema } from 'nexus'
2
3schema.scalarType({
4 name: 'Date',
5 asNexusMethod: 'date',
6 description: 'Date custom scalar type',
7 parseValue(value) {
8 return new Date(value)
9 },
10 serialize(value) {
11 return value.getTime()
12 },
13 parseLiteral(ast) {
14 if (ast.kind === Kind.INT) {
15 return new Date(ast.value)
16 }
17 return null
18 },
19})

unionType

GraphQL Docs for Union Types

Union types are very similar to interfaces, but they don't get to specify any common fields between the types.

Signature

1unionType(config: NexusUnionTypeConfig): NexusUnionTypeDef

NexusUnionTypeConfig options

  • name (required): Name of your type
  • description (optional): The description to annotate the GraphQL SDL
  • deprecation (optional): Info about a field deprecation. Formatted as a string and provided with the deprecated directive on field/enum types and as a comment on input field
  • rootTyping (optional): Root type information for this type. By default, types are extracted for any .ts file in your project. You can configure that from the schema.rootTypingsGlobPattern setting

Example

1import { schema } from 'nexus'
2
3schema.unionType({
4 name: 'MediaType',
5 description: 'Any container type that can be rendered into the feed',
6 definition(t) {
7 t.members('Post', 'Image', 'Card')
8 t.resolveType(item => item.name)
9 },
10})

arg

GraphQL Docs on Arguments

Signature

1(config: {
2 type: 'Boolean' | 'Float' | 'Int' | 'String' | 'ID'
3 default?: TYPEGEN
4 description?: string
5 list?: null | true | boolean[]
6 nullable?: boolean
7 required?: boolean
8}) => NexusArgDef
  • type The type of the argument.
  • required
    • Whether the argument is required or not.
    • When true then nullable is false.
  • nullable
    • Whether the argument is nullable or not.
    • When true then required is false.
  • list
    • Whether the argument is a list or not.
    • When true it is a list.
    • When an array, the inner boolean specifies whether the list member can be nullable.
  • description The description to annotate the GraphQL SDL

Example

Defines an argument that can be used in any object or interface type. Args can be reused in multiple locations, and it can be convenient to create your own wrappers around arguments.

1import { schema } from 'nexus'
2import { ScalarArgConfig } from 'nexus/types'
3
4function requiredInt(opts: ScalarArgConfig<number>) {
5 return schema.arg({ ...opts, required: true, type: 'Int' })
6}

<scalar>Arg

1idArg
2stringArg
3booleanArg
4intArg
5floatArg

Sugar for creating arguments of type Int String Float ID Boolean.

addToContext

Add context to your graphql resolver functions. The objects returned by your context contributor callbacks will be shallow-merged into ctx. The ctx type will also accurately reflect the types you return from callbacks passed to addToContext.

The incoming request and server response are passed to the callback in the following shape: { req: IncomingMessage, res: ServerResponse }. See below how to use them.

Example

Defining arbitrary values to your GraphQL context

1import { schema } from 'nexus'
2
3schema.addToContext(({ req, res }) => {
4 return {
5 greeting: 'Howdy!',
6 }
7})
8
9schema.queryType({
10 definition(t) {
11 t.string('hello', {
12 resolve(_root, _args, ctx) {
13 return ctx.greeting
14 },
15 })
16 },
17})

Forwarding the incoming request to your GraphQL Context

1import { schema } from 'nexus'
2
3schema.addToContext(({ req, res }) => {
4 return {
5 req
6 }
7})
8
9schema.queryType({
10 definition(t) {
11 t.string('hello', {
12 resolve(_root, _args, ctx) {
13 if (ctx.req.headers['authorization']) {
14 /* ... */
15 }
16 },
17 })
18 },
19})

use

Add schema plugins to your app. These plugins represent a subset of what framework plugins (app.use can do. This is useful when, for example, a schema plugin you would like to use has not integrated into any framework plugin. You can find a list of schema plugins here.

Example

1import { schema } from 'nexus'
2import somePlugin from 'some-plugin'
3
4schema.use(somePlugin())
5
6schema.use({
7 name: 'myPlugin',
8 description: 'my inline schema plugin',
9 // ...
10})

middleware

Run arbitrary logic before and/or after GraphQL resolvers in your schema. Middleware is run as a first-in-first-out (FIFO) stack. The order of your middleware definitions determines their order in the stack.

Signature

1schema.middleware((config: CreateFieldResolverInfo) => MiddlewareFn | undefined)): void

schema.middleware expect a function with the signature (root, args, ctx, info, next) to be returned.

If the current middleware function does not end the request-response cycle, it must call next to pass control to the next middleware function, until the actual GraphQL resolver gets called.

Note: You can skip the creation of a middleware by returning undefined instead of a middleware.

Example: Simple middlewares

1// graphql.ts
2import { schema } from 'nexus'
3
4schema.middleware(_config => {
5 return async (root, args, ctx, info, next) => {
6 ctx.log.info('before - middleware 1')
7 const result = await next(root, args, ctx, info)
8 ctx.log.info('after - middleware 1')
9 return result
10 }
11})
12
13schema.middleware(_config => {
14 return async (root, args, ctx, info, next) => {
15 ctx.log.info('before - middleware 2')
16 const result = await next(root, args, ctx, info)
17 ctx.log.info('after - middleware 2')
18 return result
19 }
20})
21
22schema.queryType({
23 definition(t) {
24 t.string('hello', (_root, _args, ctx) => {
25 ctx.log.info('executing resolver')
26 return Promise.resolve('world')
27 })
28 },
29})
30
31/**
32 * Output
33 * before - middleware 1
34 * before - middleware 2
35 * executing resolver
36 * after - middleware 2
37 * after - middleware 1
38 */

Example: Trace resolvers completion time of the Query type only

1import { schema } from 'nexus'
2
3schema.middleware(config => {
4 if (config.parentTypeConfig.name !== 'Query') {
5 return
6 }
7
8 return async (root, args, ctx, info, next) => {
9 const startTimeMs = new Date().valueOf()
10 const value = await next(root, args, ctx, info)
11 const endTimeMs = new Date().valueOf()
12 const resolver = `Query.${config.fieldConfig.name}`
13 const completionTime = endTimeMs - startTimeMs
14
15 ctx.log.info(`Resolver '${resolver}' took ${completionTime} ms`, {
16 resolver,
17 completionTime,
18 })
19
20 return value
21 }
22})
23
24schema.queryType({
25 definition(t) {
26 t.string('hello', async () => {
27 // Wait two seconds
28 await new Promise(res => setTimeout(res, 2000))
29 return 'world'
30 })
31 },
32})
33
34/**
35 * Output:
36 * ● server:request Resolver 'Query.hello' took 2001 ms -- resolver: 'Query.hello' time: 2001
37 */

importType

Signature

1(scalarType: GraphQLScalarType, methodName?: string): GraphQLScalarType
2(type: GraphQLNamedType): GraphQLNamedType

schema.importType is useful for adding existing GraphQL.js types into your Nexus schema.

Check out this repository for a handful list of useful scalar types that might be useful to your GraphQL API.

When passing a GraphQLScalarType, you can additionally pass a methodName as a second parameter, which will augment the t parameter of your definition builder with a convenient method to create a field of the associated type.

Example: Adding a date scalar type

1import { schema } from 'nexus'
2import { GraphQLDate } from 'graphql-iso-date'
3
4schema.importType(GraphQLDate, 'date')
5
6schema.objectType({
7 name: 'SomeObject',
8 definition(t) {
9 t.date('createdAt') // t.date() is now available (with types!) thanks to `importType`
10 },
11})

schema.importType can also be used to add types from an existing GraphQL schema into your Nexus schema. This is useful to incrementally adopt Nexus if you already have a GraphQL schema built with a different technology than Nexus.

Example: Adding types from a schema-first schema

1import { schema } from 'nexus'
2import { existingSchema } from './existing-schema'
3
4Object.values(existingSchema.getTypeMap()).forEach(schema.importType)

Type Glossary

I FieldConfig

1{
2 type: string
3 args?: Args
4 description?: string
5 deprecation?: string
6 nullable?: boolean
7 list?: true | boolean[]
8 resolve: Resolver
9}

O Args

🚧 Work in progress.

U GraphQLType

🚧 Work in progress.

I TypeBuilder

🚧 Work in progress.

I Context

🚧 Work in progress.

I ResolverInfo

🚧 Work in progress.

I Node

🚧 Work in progress.

I NonNullConfig

🚧 Work in progress.

1{
2 /**
3 * Whether output fields are non-null by default.
4 *
5 * type Example {
6 * field: String!
7 * otherField: [String!]!
8 * }
9 *
10 * @default true
11 */
12 output?: boolean;
13 /**
14 * Whether input fields (field arguments, input type members)
15 * are non-null by default.
16 *
17 * input Example {
18 * field: String
19 * something: [String]
20 * }
21 *
22 * @default false
23 */
24 input?: boolean;
25}

I RootTypingImport

🚧 Work in progress.

1{
2 /**
3 * File path to import the type from.
4 */
5 path: string;
6 /**
7 * Name of the type we want to reference in the `path`
8 */
9 name: string;
10 /**
11 * Name we want the imported type to be referenced as
12 */
13 alias?: string;
14}

F Resolver

🚧 Work in progress.

S NexusGenBackingTypes

🚧 Work in progress.

By default, types are extracted for any .ts file in your project. You can configure that from the schema.rootTypingsGlobPattern setting

Edit this page on Github