"defineObjectType" from $Types and what I found I during the creation of it.

[Akxe]

Schema

model Cart {
  cartID        Int        @id @default(autoincrement()) @db.UnsignedSmallInt
  startPeriodID Int        @db.UnsignedSmallInt
  endPeriodID   Int        @db.UnsignedSmallInt
  personID      Int?       @map("idOsoby") @db.UnsignedSmallInt
  name          String     @db.VarChar(45)
  email         String     @db.VarChar(45)
  adsMotive     String     @db.VarChar(45)
  goal          String?    @db.Text
  info          String?    @db.Text
  PeriodEnd     Period     @relation("Cart_endPeriodIDToPeriod", fields: [endPeriodID], references: [periodID])
  assignedTo    Person?    @relation(fields: [personID], references: [personID])
  PeriodStart   Period     @relation("Cart_startPeriodIDToPeriod", fields: [startPeriodID], references: [periodID])
  CartItem      CartItem[]

  @@index([personID], name: "cartAssignement_idx")
  @@index([endPeriodID], name: "cartPeriodEnd_idx")
  @@index([startPeriodID], name: "cartPeriodStart_idx")
}

model CartItem {
  cartID    Int     @db.UnsignedSmallInt
  carrierID Int     @map("NCis")
  nosice    Carrier @relation(fields: [carrierID], references: [carrierID])
  Cart      Cart    @relation(fields: [cartID], references: [cartID])

  @@id([cartID, carrierID])
  @@index([carrierID], name: "cartCarrier_idx")
}

Function with types (fully working types! 😮)

interface $Type {
  $name: string;
  $description: string | null;
  [index: string]: any
}

type KeysOfType<O, T> = {
  [P in keyof O]: O[P] extends T ? P : never;
}[keyof O];

// Using these would be awesome for `NexusNonNullDef` and `NexusNullDef`
//type PrimitiveKeys = 'Int' | 'String' | 'Boolean' | 'DateTime';
//type ObjectKeys = $Type;

type DbKey<T extends $Type> = KeysOfType<T, { name: string, type: NexusNonNullDef<any> | NexusNullDef<any>, description?: string }>;

function defineObjectType<T extends $Type>(
  type: T,
  keys: DbKey<T>[],
  callback?: (
    t: ObjectDefinitionBlock<T['$name']>, keyWithResolver: <K extends DbKey<T>>(key: K, resolve: FieldResolver<T['$name'], T[K]['name']>) => void,
  ) => void,
) {
  return objectType({
    name: type.$name,
    description: type.$description ?? undefined,
    definition(t) {
      keys.forEach(key => {
        const keyDef = type[key];
        t.field(
          keyDef.name,
          {
            type: keyDef.type,
            description: keyDef.description,
          },
        );
      });
      callback?.(t, (key, resolve) => {
        t.field(type[key].name, {
          type: type[key].type,
          resolve,
        });
      });
    },
  });
}

defineObjectType(
  Cart,
  [
    'cartID',
    'email',
    'startPeriodID',
    'endPeriodID',
  ],
  (t, keyWithResolver) => {
    keyWithResolver('PeriodStart', (cart, args, ctx, info) => {
      throw new Error('Not implemented...');
    });
    t.field('customField', (cart, args, ctx, info) => {
      throw new Error('Not implemented...');
    });
  },
);

My feelings on this

Invalid index.d.ts (in node_modules/nexus-prisma/dist/runtime)

This is probably referring to current midterms (19.3.2021)

interface Cart {
  $name: 'Cart'
  $description: null
  cartID: {
    /** The name of this field. */
    name: 'cartID'
    /** The type of this field. */
    type: NexusCore.NexusNonNullDef<'Int'>
    /** The documentation of this field. */
    description: undefined
  }
  startPeriodID: {
    name: 'startPeriodID'
    type: NexusCore.NexusNonNullDef<'Int'>
    description: undefined
  }
  endPeriodID: {
    name: 'endPeriodID'
    type: NexusCore.NexusNonNullDef<'Int'>
    description: undefined
  }
  personID: {
    name: 'personID'
    type: NexusCore.NexusNullDef<'Int'>
    description: undefined
  }
  name: {
    name: 'name'
    type: NexusCore.NexusNonNullDef<'String'>
    description: undefined
  }
  email: {
    name: 'email'
    type: NexusCore.NexusNonNullDef<'String'>
    description: undefined
  }
  adsMotive: {
    name: 'adsMotive'
    type: NexusCore.NexusNonNullDef<'String'>
    description: undefined
  }
  goal: {
    name: 'goal'
    type: NexusCore.NexusNullDef<'String'>
    description: undefined
  }
  info: {
    name: 'info'
    type: NexusCore.NexusNullDef<'String'>
    description: undefined
  }
  PeriodEnd: {
    name: 'PeriodEnd'
    type: NexusCore.NexusNonNullDef<'Period'>
    description: undefined
  }
  assignedTo: {
    name: 'assignedTo'
    type: NexusCore.NexusNullDef<'Person'>
    description: undefined
  }
  PeriodStart: {
    name: 'PeriodStart'
    type: NexusCore.NexusNonNullDef<'Period'>
    description: undefined
  }
  CartItem: {
    name: 'CartItem'
    type: NexusCore.ListDef<CartItem> | NexusCore.NexusNonNullDef<CartItem> // This is the first line to throw error
    description: undefined
  }
}
interface CartItem {
  $name: 'CartItem'
  $description: null
  cartID: {
    name: 'cartID'
    type: NexusCore.NexusNonNullDef<'Int'>
    description: undefined
  }
  carrierID: {
    name: 'carrierID'
    type: NexusCore.NexusNonNullDef<'Int'>
    description: undefined
  }
  nosice: {
    name: 'nosice'
    type: NexusCore.NexusNonNullDef<'Carrier'>
    description: undefined
  }
  Cart: {
    name: 'Cart'
    type: NexusCore.NexusNonNullDef<'Cart'>
    description: undefined
  }
}

Error:

Namespace '"c:/Users/akxe/Documents/programming/rita/node_modules/nexus/dist/core"' has no exported member 'ListDef'.
// and
Type 'CartItem' does not satisfy the constraint 'NexusNonNullableTypes'.
  Type 'CartItem' is missing the following properties from type 'NexusArgDef<any>': name, config, value

Naming

Cart.$name vs Cart.field.name, type and description, it is unexpected to say the least. I would propose to use Symbol supported from nodeJS 6.4. It would prevent collision if someone would name their column $name, which might happen...

Type of $description should be string | undefined

Rather than string | null, $description should be string | undefined. It would allow being mapped directly to objectType.description.

Automatic comments

Description of just two tables above spans across 854 lines!. If the description of name and description would be single-line it would result in 144 lines. Much more readable.

[jasonkuhrt]

Thanks for this feedback!

Rather than string | null, $description should be string | undefined. It would allow being mapped directly to objectType.description.

This is done now thanks to @lvauvillier

I would propose to use Symbol

To go further on this please open an issue with examples showing why this is a better DX in multiple use-cases.

Description of just two tables above spans across 854 lines!. If the description of name and description would be single-line it would result in 144 lines. Much more readable.

It is optimized for the doc experience of writing code and working in-context at call sites. Not particularly for opening the generated runtime module.

Again to go further on this please open an issue with examples showing why this is a better DX in multiple use-cases with another approach.

I think it might make sense to allow documentation to be disabled, as a simple boolean flag.

Error:

Its not expected that errors can happen so issue welcome!

[Akxe]

Rather than string | null, $description should be string | undefined. It would allow being mapped directly to objectType.description.

This is done now thanks to @lvauvillier

Thanks! :)

I would propose to use Symbol

To go further on this please open an issue with examples showing why this is a better DX in multiple use-cases.

I am not sure what would happen if someone would happen, if someone would name their column $name of $description, wouldn't it result in a collision and thus either missing column or invalid $name/$description type?

Description of just two tables above spans across 854 lines!. If the description of name and description would be single-line it would result in 144 lines. Much more readable.

It is optimized for the doc experience of writing code and working in-context at call sites. Not particularly for opening the generated runtime module.

Again to go further on this please open an issue with examples showing why this is a better DX in multiple use-cases with another approach.

I don't have the comment in front of me, but I think it was something like "Comment for column/table is not provided, add one as so: ...".

It is however true that it does not really matter...

[jasonkuhrt]

$ is not a valid Prisma field identifier so no collision risk.

[Akxe]

Didn't know that. That's solved then... Thanks for reading it thought :)