-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(ts): add overloads to withAuth middleware #7999
fix(ts): add overloads to withAuth middleware #7999
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
@rexfordessilfie is attempting to deploy a commit to the authjs Team on Vercel. A member of the Team first needs to authorize it. |
Thanks, could you open this against the |
Thanks! Will do. |
6ffc444
to
18c97fb
Compare
Done, @balazsorban44 ✅. Let me know if I did everything right! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed bug report and the PR, @rexfordessilfie 🙏 I left a comment, let me know what you think!
): <Req extends Request = NextRequestWithAuth>( | ||
request: Req, | ||
event: NextFetchEvent | ||
) => ReturnType<NextMiddlewareWithAuth> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this type is NextMiddlewareWithAuth
with a different request
type
How do you think if we do it like this:
export function withAuth(): ReturnType<NextMiddlewareWithAuth>
export function withAuth(
req: NextRequestWithAuth
): ReturnType<NextMiddlewareWithAuth>
export function withAuth(
req: NextRequestWithAuth,
event: NextFetchEvent
): ReturnType<NextMiddlewareWithAuth>
export function withAuth(
req: NextRequestWithAuth,
options: NextAuthMiddlewareOptions
): ReturnType<NextMiddlewareWithAuth>
export function withAuth(
middleware: NextMiddlewareWithAuth,
options: NextAuthMiddlewareOptions
): NextMiddlewareWithAuth
export function withAuth(
middleware: NextMiddlewareWithAuth
): NextMiddlewareWithAuth
export function withAuth(
options: NextAuthMiddlewareOptions
): NextMiddlewareWithAuth
Doing this way, we will keep the params consistent with the return type: ReturnType<NextMiddlewareWithAuth> | NextMiddlewareWithAuth
.
In the app code, it will be like this:
import { NextRequestWithAuth, withAuth } from "next-auth/middleware"
import { NextFetchEvent } from "next/server";
export default async function middleware(req: NextRequestWithAuth, event: NextFetchEvent) {
const localeStr = req.headers.get("Accept-Language");
const locale = localeStr?.split(";")[0].split(",")[0];
const withAuthMiddleware = withAuth({
callbacks: {},
pages: {
signIn: `/?locale=${locale}`,
},
});
return await withAuthMiddleware(req, event);
}
One different is how we type the req
object - we can use NextRequestWithAuth
for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback! Yes, you are right. It was a copy directly from NextMiddlewareWithAuth
.
I did not consider using req: NextRequestWithAuth
directly. I noticed I was getting type errors when it was req: Request
and so I made a generic version of NextMiddlewareWithAuth
to fix the type errors!
I will switch to this and request a re-review!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
my build is failing,
|
☕️ Reasoning
The
withAuth
middleware returns different values depending on provided arguments. In the current implementation it returns a union such as:NextMiddlewareWithAuth | NextMiddlewareResult | ...
.This union is type is not narrow enough for use in scenarios where we expect a callable
NextMiddlewareWithAuth
that we can invoke later after getting some outside context from the middlewarerequest
object.In summary, when we want to do something like this:
Solution: This PR adds type overloads such that the types narrow down as expected depending on the arguments supplied to
withAuth
. This lets us do the above without any type issues.🧢 Checklist
🎫 Affected issues
Please scout and link issues that might be solved by this PR.
Fixes: #7997
📌 Resources