Type inference lost for callback parameter

[Azzerty23]

Steps to reproduce

This issue occurs in the better-auth Next.js demo, specifically in the organization plugin callback.

Original Repository: https://github.com/better-auth/better-auth/tree/main/demo/nextjs
Repro (extracted demo folder with tsgo config, without any other changes): https://github.com/Azzerty23/tsgo-issue-repro

File: lib/auth.ts, line 135

Minimal reproduction:

import { organization } from "better-auth/plugins";

// Inside betterAuth configuration:
plugins: [
  organization({
    async sendInvitationEmail(data) {  // ← 'data' parameter loses type with ts-go
      // TypeScript should infer a complex type for 'data' from the plugin's type definitions
      ...
    },
  }),
]

TypeScript configuration:

{
  "compilerOptions": {
    "target": "ES2017",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "bundler"
  }
}

Behavior with typescript@5.9.3

Using the standard TypeScript LSP (VSCode), the data parameter is correctly inferred with this complete type:

sendInvitationEmail(data: {
    id: string;
    role: string;
    email: string;
    organization: {
        id: string;
        name: string;
        slug: string;
        createdAt: Date;
        logo?: string | null | undefined;
        metadata?: any;
    };
    invitation: {
        id: string;
        organizationId: string;
        email: string;
        role: string;
        status: "pending" | "accepted" | "rejected" | "canceled";
        inviterId: string;
        expiresAt: Date;
        createdAt: Date;
        teamId?: string | null | undefined;
    };
    inviter: {
        id: string;
        organizationId: string;
        userId: string;
        role: string;
        createdAt: Date;
    } & {
        user: {
            id: string;
            createdAt: Date;
            updatedAt: Date;
            email: string;
            emailVerified: boolean;
            name: string;
            image?: string | ... 1 more ... | undefined;
        };
    };
}): Promise<void>

The IDE provides full autocomplete and type checking for data.email, data.inviter.user.name, data.organization.name, etc.

Behavior with tsgo

When using ts-go's LSP, the data parameter is inferred as any, resulting in:

• Loss of autocomplete for all properties
• Loss of type safety
• No errors when accessing non-existent properties

This appears to be a regression in type inference for callback parameters where the type should be inferred from the plugin's type definition (from the better-auth/plugins package).

Additional context

• Environment: VSCode with ts-go LSP
• Library: better-auth@^1.4.3 with TypeScript type definitions
• Impact: This affects developer experience significantly, as callback parameters in plugin configurations lose all type information
• Pattern: The issue occurs with callback functions passed as options to plugin configuration functions where the callback parameter type should be inferred from the plugin's type signature

The type information is available in the better-auth/plugins package type definitions, but ts-go seems unable to propagate it to the callback parameter.

[jakebailey]

This is certainly strange.

import { betterAuth } from "better-auth";
import { organization } from "better-auth/plugins";

export const auth = betterAuth({
	plugins: [
		organization({
			async sendInvitationEmail(data) {},
		}),
	],
});


organization({
	async sendInvitationEmail(data) {},
})

Only the first data is implicit any.

If you modify organization and remove its return type in favor of any, then the param starts working.

[jakebailey]

Minimized:

declare const betterAuth: <Options extends BetterAuthOptions>(options: Options) => void;

type BetterAuthOptions = {
    plugins?: ([] | BetterAuthPlugin[]) | undefined;
};

type BetterAuthPlugin = {
    options?: Record<string, any> | undefined;
};

declare function organization<O extends OrganizationOptions>(options?: O | undefined): { options: O; };

interface OrganizationOptions {
    sendInvitationEmail?: ((data: { id: string }) => Promise<void>) | undefined;
}

betterAuth({
    plugins: [
        organization({
            async sendInvitationEmail(data) {},
        }),
    ],
});

organization({
    async sendInvitationEmail(data) {},
});

[Azzerty23]

I did some research for my own understanding...

declare const betterAuth: <Options extends BetterAuthOptions>(
	options: Options,
) => void;

type BetterAuthOptions = {
	plugins?: BetterAuthPlugin[];
};

type BetterAuthPlugin = {
	options?: Record<string, any;
};

// No type issue with:
// type BetterAuthPlugin = {
// 	options?: Record<string, (data: {id: string}) => void>;
// };

declare function organization<O extends OrganizationOptions>(
	options?: O,
): { options: O };

interface OrganizationOptions {
	sendInvitationEmail?: (data: { id: string }) => Promise<void>;
}

interface KeyOptions {
	key?: (data: { id: string }) => void;
}

declare function buildOptions<O>(value: O): { options: O };
declare function buildConstrainedOptions<O extends KeyOptions>(
	value: O,
): { options: O };

declare function logRecord(data: { id: string }): void;

betterAuth({
	plugins: [
		{ options: { key: logRecord } }, // type inferred correctly
		{ options: { key: (data) => logRecord(data) } }, // type inferred correctly (equivalent to above)

		// functions with type arguments -> type-safe
		buildConstrainedOptions<{ key: (data: { id: string }) => void }>({
			key: (data) => logRecord(data),
		}),
		buildOptions<{ key: (data: { id: string }) => void }>({
			key: (data) => logRecord(data),
		}),
		organization<{
			sendInvitationEmail?: (data: { id: string }) => Promise<void>;
		}>({
			async sendInvitationEmail(data) {
				console.log(data);
			},
		}),

		// functions without type arguments -> type inference issue
		// data is inferred as 'any' from BetterAuthPlugin (in Record<string, any>)
		buildConstrainedOptions({ key: (data) => logRecord(data) }),
		buildOptions({ key: (data) => logRecord(data) }),
		organization({
			async sendInvitationEmail(data) {
				console.log(data);
			},
		}),
	],
});

organization({
	async sendInvitationEmail(data) {
		console.log(data);
	},
}); // type-safe

buildConstrainedOptions({
	key: (data) => {
		console.log(data);
	},
}); // type-safe

buildOptions<{ key: (data: { id: string }) => void }>({
	key: (data) => {
		console.log(data);
	},
}); // type-safe

buildOptions({
	key: (data) => {
		console.log(data);
	},
}); // expected type issue

[ahejlsberg]

Interestingly, this fails with the nightly build of TS 6.0 as well.

Failing example with 6.0 nightly

[jakebailey]

Oh, huh. Bisect says microsoft/TypeScript#58910, then, which is a backport of a fix you applied to the Go code that was also a fix to a bunch of TS issues @Andarist also had been working on for a while.

[Andarist]

I think this change only created a new situation in which a return type inference can spoil contextual types. This could already easily happen in TS 5.9 (and earlier) - the provided repro runs into is as soon as we make options non-optional:

type BetterAuthPlugin = {
-    options?: Record<string, any>;
+    options: Record<string, any>;
};

You can see it in this TS playground.

It's not my place to judge if this change should be reverted or not based on this single (so far?) regression. However, I think there exists a better fix for this issue as a whole. Not that I know how to implement it right now though.

[Azzerty23]

If we remove the optionality in the "Failing example with 6.0 nightly" above, it works: TS playground

[Andarist]

This boils down to:

type FilterMatching<T, Constraint> = T extends any
  ? T extends Constraint
    ? T
    : never
  : never;

type ReturnTypeInferredType = Record<string, any> | undefined;

interface OrganizationOptions1 {
  sendInvitationEmail?: ((data: { id: string }) => Promise<void>) | undefined;
}

type Result1 = FilterMatching<ReturnTypeInferredType, OrganizationOptions1>;
//   ^? type Result1 = { [x: string]: any; }

interface OrganizationOptions2 {
  sendInvitationEmail: ((data: { id: string }) => Promise<void>) | undefined;
}

type Result2 = FilterMatching<ReturnTypeInferredType, OrganizationOptions2>;
//   ^? type Result2 = never

This return type inference doesn't satisfy the constraint with a required property:

// Type 'Record<string, any>' does not satisfy the constraint 'OrganizationOptions'.
//   Property 'sendInvitationEmail' is missing in type 'Record<string, any>' but required in type 'OrganizationOptions'.(2344)
organization<Record<string, any>>({
    async sendInvitationEmail(data) {},
});

It seemingly looks very similar but it's fundamentally different from the demo I have shown.

In mine, even in TS 5.9, a required property ends up inferring Record<string, any> and that's accepted by the constraint in that demo as-is - without any extra filtering that is responsible for this change we are discussing here.

In yours the required property in the target constraints makes Record<string, any> incompatible with that constraint so its rejected and replaced with the actual constraint.

[Azzerty23]

I understand better, thank you for the detailed explanation!

[ahejlsberg]

My take on this...

We prefer any inferences we can make from parameters or return types when determining contextual types. Type parameter constraints come into play only when we have no inferences. I think that is the right principle.

In the example, when the call to organization is nested within a call to betterAuth, we make a return type inference for O from the parameter type of betterAuth to the return type of organization. The inferred type Record<string, any> | undefined is narrowed down to Record<string, any>, which satisfies the constraint OrganizationOptions (a very weak type because it has no non-optional properties). So, we use Record<string, any> as the contextual type for the sendInvitationEmail method, and thus we have no specific type for the data parameter.

The example worked in 5.9 only because we didn't attempt to narrow return type inferences, and the inference of Record<string, any> | undefined isn't compatible with OrganizationOptions (because of the undefined).

Both of the types involved here, Record<string, any> and OrganizationOptions are "weak", in that they're very permissive, and both are assignable to each other. So, there's nothing that would make us prefer one over the other. That's just an unfortunate fact of this scenario, but I don't think it merits changing things (and, TBH, I'm not sure what the change would be).

A fairly easy fix is to use a NoInfer marker in the return type of organization:

declare function organization<O extends OrganizationOptions>(options?: O): { options: NoInfer<O> };

This suppresses any return type inferences, which, in this scenario, are likely not useful anyway.

[Azzerty23]

Amazing, thank you for breaking it down so clearly and for providing the solution. I'll open a PR for Better Auth (for future compatibility) and let the team close the issue. Good luck on the road to v7!