next-auth: `providers` doesn't accept type `OAuthConfig`

This is kind of embarrassing, out of the box default example throws this type errors, bypassing the type checker is not a solution

Let’s get the issue fixed, every single user trying auth.js with typescript hits this issue and makes no sense.

Same issue here. Working around:

providers: [
	//@ts-expect-error issue https://github.com/nextauthjs/next-auth/issues/6174
	GitHub({ clientId: GITHUB_ID, clientSecret: GITHUB_SECRET })
]

Including “just ignore the red underlines” should never be considered.

TypeScript complains for a reason, so this should be fixed, bypassing the linting and disabling ts checks is just a temporary solution and shouldn’t be considered a regular practice and should not be mentioned in the docs. Ever.

I literally checked 2 hours ago if this has been resolved, go away stale bot.

I did some digging and it looks like it’s the inconsistency between interface Profile between packages

// packages/next-auth/src/core/types.ts

export interface Profile {
  sub?: string
  name?: string
  email?: string
  image?: string
}

// packages/core/src/types.ts

export interface Profile {
  sub?: string | null
  name?: string | null
  email?: string | null
  image?: string | null
}

as you can see one of them accepts string | undefined while the other only does string | undefined | null . I tried changing the latter to string | undefined however I’m not familiar with the codebase and running lint on the project doesn’t seem to catch the error either way, also the apps/dev/sveltekit/hooks file doesn’t seem to grab types from the auth/sveltekit package properly for me.

Just commenting to avoid stale bot. Is also happening to me, using sveltekit and drizzle adapter

Just hit this. Commenting to avoid stale bot.

Hey @enBonnet, I still had to typecast it using

as Provider[]

Not SvelteKit specific. When a provider is imported, it should extend the Profile interface, so it’s correctly typed in places like the jwt callback.

The tricky part is that it should be dependent on the value of Account#providerAccountId.

Eg.:

jwt({ account, profile }){
  if(account?.providerAccountId === "github") {
    // profile should have the shape of `GithubProfile` inside here
  }
}

We can tackle half the problem by module augmentation, i.e.:

declare module "../types.js" {
  interface Profile extends GithubProfile {}
}

Adding this to https://github.com/nextauthjs/next-auth/blob/main/packages/core/src/providers/github.ts

But the last I tried, I could not augment the same interface with more than one Profile at the same time.

If TypeScript gurus read this, help would be appreciated!

November stale bot comment, still revisiting this often a month

if you have multiple providers, you also use like this as Provider[]

export const authjs = SvelteKitAuth({
	debug: dev,
	providers: [
		Google({
			clientId: envPri.GOOGLE_ID,
			clientSecret: envPri.GOOGLE_SECRET,
			authorization: { params: { prompt: 'consent' } }
		}),
		AzureAD({
			clientId: envPri.AZURE_AD_CLIENT_ID,
			clientSecret: envPri.AZURE_AD_CLIENT_SECRET,
			tenantId: envPri.AZURE_AD_TENANT_ID,
			authorization: { params: { scope: 'openid profile User.Read email' } }
			// client: {},
		}),
		GitHub({ clientId: envPri.GITHUB_ID, clientSecret: envPri.GITHUB_SECRET })
	] as Provider[]
}) satisfies Handle;

When I tried this, I realised that the @auth/sveltekit is using @auth/core@0.3.0 but the latest auth/core is 0.4.0, pinning the version of @auth/core fixed it for me.

I don’t think so, this is just a workaround, we should fix it instead.

Definitely agree it should be fixed, but at least a note in the docs in the meantime couldn’t hurt.

We can tackle half the problem by module augmentation, i.e.:

declare module "../types.js" {
  interface Profile extends GithubProfile {}
}

Adding this to https://github.com/nextauthjs/next-auth/blob/main/packages/core/src/providers/github.ts

But the last I tried, I could not augment the same interface with more than one Profile at the same time.

If TypeScript gurus read this, help would be appreciated!

This sounds like perhaps a backwards way to do it. You’re essentially tricking the TS compiler into thinking GithubProfile matches the interface of Profile, which can make the error go away, but doesn’t solve the root problem.

Semantically, I would expect the opposite: GithubProfile (more specific) should be an extension of Profile (more general). I’m not that familiar with the internal types of AuthJS yet, but I think this is written incorrectly (or at least oddly):

@auth/core/src/providers/github.ts

export default function GitHub<Profile extends GithubProfile>(
  options: OAuthUserConfig<Profile>
): OAuthConfig<Profile> {
 ....
 }

Here we’re telling TS that the generic type used within the function (Profile) should extend from GithubProfile, but shouldn’t the actual GithubProfile type extend from the actual Profile type instead?:

@auth/core/src/providers/index.ts

export type Provider<P extends Profile = Profile> = (
  | OIDCConfig<P>
  | OAuth2Config<P>
  | EmailConfig
  | CredentialsConfig
) & {
  options: Record<string, unknown>
}

Which would make this closer to the solution?

@auth/core/src/providers/github.ts

export interface GithubProfile extends Profile {
...
}

export default function GitHub(
  options: OAuthUserConfig<GithubProfile>
): OAuthConfig<GithubProfile> {
...
}

Then, we don’t need to provide the generic with an extension. We just let TS do its job. Just seems like there’s a lot of odd TS stuff under the hood here. It looks like the type mismatch is still further down in inference, within the OAuthUserConfig type.

It has been a long time with this issue open, almost a year, I see that in the official examples we are using the satisfies NextAuthConfig approach there is the example: https://github.com/nextauthjs/next-auth/blob/465e882176de5c9e1bc5a482c429ba8d54c55e22/apps/examples/nextjs/auth.ts#L143C27-L144C1

Maybe we should update the docs for TS to add this instead of going through every provider to fix it?

Good use case for satisfies in the meantime:

  providers: [
    Discord({
      clientId: process.env.DISCORD_CLIENT_ID,
      clientSecret: process.env.DISCORD_CLIENT_SECRET,
    }),
  ] satisfies Provider[],
});

Furthermore, doing this type assertion should be in the docs, as I imagine that everyone will run into this problem the moment they start using SvelteKitAuth.

I don’t think so, this is just a workaround, we should fix it instead.