`providers` doesn't accept type `OAuthConfig<T>`

[asrvd]

Environment

System: OS: Windows 10 10.0.22000 CPU: (4) x64 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz Memory: 2.03 GB / 7.73 GB Binaries: Node: 16.16.0 - ~\scoop\apps\nodejs-lts\current\node.EXE npm: 8.11.0 - ~\scoop\apps\nodejs-lts\current\npm.CMD Browsers: Edge: Spartan (44.22000.120.0), Chromium (108.0.1462.54) Internet Explorer: 11.0.22000.120

Reproduction URL

https://github.com/nextauthjs/sveltekit-auth-example

Describe the issue

the providers option in SvelteKitAuth accepts type Provider<Profile>[] but the Github Provider is of type OAuthConfig<GithubProfile> https://github.com/nextauthjs/next-auth/issues/6170#issuecomment-1364538419

Error: Type 'OAuthConfig<GithubProfile>' is not assignable to type 'Provider<Profile>'.
  Type 'OIDCConfig<GithubProfile>' is not assignable to type 'Provider<Profile>'.
    Type 'OIDCConfig<GithubProfile>' is not assignable to type 'OIDCConfig<Profile> & { options: Record<string, unknown>; }'.
      Type 'OIDCConfig<GithubProfile>' is not assignable to type 'OIDCConfig<Profile>'.
        Types of property 'profile' are incompatible.
          Type 'ProfileCallback<GithubProfile> | undefined' is not assignable to type 'ProfileCallback<Profile> | undefined'.
            Type 'ProfileCallback<GithubProfile>' is not assignable to type 'ProfileCallback<Profile>'.
              Types of parameters 'profile' and 'profile' are incompatible.
                Type 'Profile' is missing the following properties from type 'GithubProfile': login, id, node_id, avatar_url, and 26 more.

How to reproduce

Clone the repo, install deps, navigate to the hooks.server.ts file or run pnpm check

Expected behavior

there shouldnt be any type error

[balazsorban44]

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!

[xmlking]

Until we find a permanent solution, to disable linting (red wavy underline) in VS Code, I am using below comments at top of the file.

/* eslint-disable */
// @ts-nocheck

[jrmoynihan]

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.

[enBonnet]

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 })
]

[oskarrough]

Mine stopped complaining after doing this. I don't know if it's the right way though.

import {SvelteKitAuth} from '@auth/sveltekit'
import type {Handle} from '@sveltejs/kit'
import type {Provider} from '@auth/core/providers'
import type {Profile} from '@auth/core/types'

SvelteKitAuth({
  providers: [
    Auth0Provider({
      // ...
    })  as Provider<Profile>
  ]
}) satisfies Handle

[Zamiell]

Piggybacking on the previous comment, Profile is already the default generic parameter, so you can simply the type assertion to this:

import { DISCORD_CLIENT_ID, DISCORD_CLIENT_SECRET } from "$env/static/private";
import type { Provider } from "@auth/core/providers";
import Discord from "@auth/core/providers/discord";
import { SvelteKitAuth } from "@auth/sveltekit";

export const handle = SvelteKitAuth({
  providers: [
    Discord({
      clientId: DISCORD_CLIENT_ID,
      clientSecret: DISCORD_CLIENT_SECRET,
    }),
  ] as Provider[],
});

(Using Discord instead of Auth0 of course, but yeah.)

[Zamiell]

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.

[xmlking]

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;

[enBonnet]

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.

[JoRyGu]

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.

[jschlesser]

A note in the docs and a note to ignore the 'red squiggles' in the official template too. https://github.com/nextauthjs/sveltekit-auth-example. I spent a couple of hours thinking my local env had an odd version or something till I ran the template in a codespace on GitHub and got the same 'red squiggles'.

[bartektelec]

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.

[JoRyGu]

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.

Right, but the framework is clearly under active development and straight up doesn't work without bypassing the type check currently. A note about the failing type check being a known issue with a temporary workaround in the docs is entirely appropriate at this stage of development.

[manucorporat]

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

[jay-dee7]

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/[email protected] but the latest auth/core is 0.4.0, pinning the version of @auth/core fixed it for me.

[enBonnet]

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/[email protected] but the latest auth/core is 0.4.0, pinning the version of @auth/core fixed it for me.

Does it work for you without anything else? Any comment or type assertion?

[multiplehats]

Ran into the same issue, I don't see @autho/core pinned to 0.3.0 though. It just uses the latest in the workspace

[jay-dee7]

Hey @enBonnet, I still had to typecast it using

as Provider[]

[stale[bot]]

It looks like this issue did not receive any activity for 60 days. It will be closed in 7 days if no further activity occurs. If you think your issue is still relevant, commenting will keep it open. Thanks!

[enBonnet]

Thanks @stale (lol), I'll take a look at this issue

[bartektelec]

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.

[timmywil]

Just hit this. Commenting to avoid stale bot.

[jensilo]

It's definitely still an issue, experiencing it with AzureAd as well.

[manucorporat]

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

[Logan9312]

Can confirm, I spent quite some time trying to figure this out because following the getting started guide leads to this error and causes a lot of confusion

[SilentEchoGM]

Good use case for satisfies in the meantime:

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

[stale[bot]]

It looks like this issue did not receive any activity for 60 days. It will be closed in 7 days if no further activity occurs. If you think your issue is still relevant, commenting will keep it open. Thanks!

[simbazzczz]

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

[TeeWallz]

Monthly stale bot comment. This is still an issue

[anton-trautman]

still facing that issue...