nextauthjs / nextauthjs/next-auth

AdapterUser type doesn't match prisma schema

Open
#7,003 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

adapters prisma triage
Dominant language
TypeScript
Stars
28.4k
Forks
4k
PR merge metrics
No merged PRs in 30d

Description

Adapter type

@next-auth/prisma-adapter

Environment

System:
OS: Windows 10 10.0.19045
CPU: (12) x64 AMD Ryzen 5 3600 6-Core Processor
Memory: 7.75 GB / 15.95 GB
Binaries:
Node: 18.14.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
npm: 9.5.0 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Spartan (44.19041.1266.0), Chromium (111.0.1661.44)
Internet Explorer: 11.0.19041.1566

npmPackages:
@next-auth/prisma-adapter: ^1.0.5 => 1.0.5

Doesn't seem to have fetched next, next-auth or react but versions are:
"react": "18.2.0",
"next": "^13.2.1",
"next-auth": "^4.19.0",

Reproduction URL

N/A

Describe the issue

The default schema for the prisma adapter marks the email as an optional field that might be null, however the AdapterUser type makes this required. Thus typescript tells me "Type 'String | null' is not assignable to type 'String'" if I try to return a result from the user model as an AdapterUser.

How to reproduce

The reason this started is because I have a separate prisma model let's call it "person", and the user model has an added personId field as well as a relation.

My user model now looks like this

model User {
  id            String      @id @default(cuid())
  name          String?
  email         String?     @unique
  emailVerified DateTime?
  image         String?
  accounts      Account[]
  sessions      Session[]

  // This is custom, the above is what's provided here as the "default": https://authjs.dev/reference/adapter/prisma#schema
  personId      String?
  Person        Person?     @relation(fields: [personId], references: [id])

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

What I wanted is to copy the adapters methods for getting the user, and adding on an include for the person, so I don't need to do a separate fetch for it. My initial try was to copy the existing adapter function

getUser: (id) => p.user.findUnique({ where: { id } }),

And doing something like this (in my authOptions):

adapter: {
    ...PrismaAdapter(prisma),
    getUser: (id: string): Awaitable<AdapterUser | null> =>
      prisma.user.findUnique({ where: { id }, include: { Person: true } }),
  },

This is where I get the error from above, as the schema doesn't guarantee there to be an email (it might be null) but the type expects there to always be.

PS. perhaps there is an easier way to make this related model available alongside the user, if so I'll happily be corrected. DS.

Expected behavior

What I'd expect is that the return from the user model could be mapped to the AdapterUser type.

I'm definitely not the expert here so I don't know what guarantees can be made about there being an email on the user. But I guess I'd either expect the AdapterUser type to mark it as optional. Or if we can guarantee it to be there, the example schema to mark the email as required (not nullable) in the DB.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with packages/next-auth/src/adapters.ts and compare AdapterUser with the default Prisma adapter schema linked in the issue. Reproduce the TypeScript error using the shown User model and custom getUser implementation; done means the adapter return type and documented schema have a clear, compatible contract.

Written by the indexing model from the issue text.

Assessment

Tech stack
nextjs, react, typescript
Domain
authentication, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.