chore: include user.id on session

[bhatvikrant]

Include user.id on session

• I reviewed linter warnings + errors, resolved formatting, types and other issues related to my work
• The PR title follows the convention we established conventional-commit
• I performed a functional test on my final commit

---

Summary

fixes #176

1. added callbacks in api-handler-prisma.ts and api-handler.ts
2. included next-auth.d.ts only when it is a next-auth scaffolding

---

[balazsorban44]

Added my suggestions.

[nexxeln]

Thank you! @balazsorban44 , great to have a review from you.

[bhatvikrant]

Added my suggestions.

Hey @balazsorban44 nice to see you here!
Thanks for the inputs

[bhatvikrant]

Have made the changes suggested by @balazsorban44

[t3dotgg]

This looks good to me, I'm fine with the session binding being "incorrect" if you don't use a DB persistence (can't imagine many if any of our users would NOT use a DB)

[juliusmarminge]

if we only include this when Prisma is also included, would that make more sense?

I'm fine with the session binding being "incorrect" if you don't use a DB persistence

I think modifying the installer to have two separate api-handlers would be better? Also not include the next-auth.d.ts if no db is included?

[juliusmarminge]

if we only include this when Prisma is also included, would that make more sense?

I'm fine with the session binding being "incorrect" if you don't use a DB persistence

I think modifying the installer to have two separate api-handlers would be better? Also not include the next-auth.d.ts if no db is included?

On second thought it doesn't really matter since the user-object's type exists whether there is a db or not. This is from a fresh t3 app with just next-auth:

So having an id on there doesn't really matter I guess...

The above solution would also require two different tsconfigs and now it's really getting annoying...

But making the user (and the id) optional in the next-auth.ts I guess would be better to keep the typesafety going?

  interface Session {
    user?: {
      id?: string;
    } & DefaultSession["user"];
  }

The current setup where they are not optional:

  interface Session {
    user: {
      id: string;
    } & DefaultSession["user"];
  }

would result in a runtime error if trying to access the id:

console.log(session?.user.id); // no type-errors, but the user-object is undefined

[bhatvikrant]

if we only include this when Prisma is also included, would that make more sense?

I'm fine with the session binding being "incorrect" if you don't use a DB persistence

I think modifying the installer to have two separate api-handlers would be better? Also not include the next-auth.d.ts if no db is included?

On second thought it doesn't really matter since the user-object's type exists whether there is a db or not. This is from a fresh t3 app with just next-auth:

So having an id on there doesn't really matter I guess...

The above solution would also require two different tsconfigs and now it's really getting annoying...

But making the user (and the id) optional in the next-auth.ts I guess would be better to keep the typesafety going?

  interface Session {
    user?: {
      id?: string;
    } & DefaultSession["user"];
  }

The current setup where they are not optional:

  interface Session {
    user: {
      id: string;
    } & DefaultSession["user"];
  }

would result in a runtime error if trying to access the id:

console.log(session?.user.id); // no type-errors, but the user-object is undefined

I agree, making user and id optional. This should be better for type-safety

[bhatvikrant]

Hey @juliusmarminge @theobr, I've made the suggested changes and the PR already has 2 approvals.
Whats next to get it merged?