clerk not compatible nextjs 15
Closed this issue ยท 16 comments
Preliminary Checks
-
I have reviewed the documentation: https://clerk.com/docs
-
I have searched for existing issues: https://github.com/clerk/javascript/issues
-
I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
-
This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.
Reproduction
xxxxxx
Publishable key
pk_test_bmF0dXJhbC1zYXdmaXNoLTc1LmNsZXJrLmFjY291bnRzLmRldiQ
Description
I am creating a new project and I have the latest version of clerk, but it is not compatible with nextjs 15.
@clerk/nextjs": "^5.7.5",
Environment
xxx
I think in the next major version this will be an actual issue
https://nextjs.org/docs/app/building-your-application/upgrading/version-15#recommended-async-usage
As they said they will throw an error now so you can fix it, but it will still works for the this version
To add to this, the stack trace shows that this is very like caused by the implementation of auth()
, in my case used within a SignedOut
component:
at new Request (node:internal/deps/undici/undici:9267:34)
at new NextRequest (.next/server/chunks/ssr/5a2f6_next_2cb2f2._.js:3350:14)
at buildRequestLike (.next/server/chunks/ssr/_2a1227._.js:48:16)
at auth (.next/server/chunks/ssr/_2a1227._.js:853:443)
at SignedOut (.next/server/chunks/ssr/_2a1227._.js:1043:433)
@drosi94 We as consumers of the Clerk SDK cannot fix it with the workaround, it's a problem the Clerk team has to fix since we receive the error to their underlying sync access.
Yes you are right they are working on it #4366
edit: As I see they changing everything to be async which may introduce more time migrating as testing it would be needed. An option would be to use the workaround for now with the sync way and migrate afterwards to the async APIs
Clerk provider not awaiting headers throws error per @clerk/nextjs": "^5.7.5" and "next": "^15.0.1-canary.1" next --turbo.
Given that Next 15 just released with massive breaking changes it's not surprise. If you have a critical application you shouldn't migrate the same day and wait for a few days until the ecosystem catches up.
Hello!
We've merged #4366 to provide compatibility with the latest Next.js release and it'll be released soon. You'll hear about that in our changelog (https://clerk.com/changelog) and once #4358 is merged it'll be released by our CI.
Thank you for your patience ๐
@LekoArts I just tried out the latest canary and at first glance it looks to be working well with all the relevant changes, but I had to apply the changes manually. I couldn't get your @clerk/upgrade
codemods to work, but chances are it's a just an issue of me trying to use it.
@LekoArts I just tried out the latest canary and at first glance it looks to be working well with all the relevant changes, but I had to apply the changes manually. I couldn't get your
@clerk/upgrade
codemods to work, but chances are it's a just an issue of me trying to use it.
same, I guess it's down for now...?
Latest canary breaks the middleware, specifically auth().protect() in clerkMiddleware
middleware.js (17:12) @ TURBOPACK__default__export.debug
TypeError: auth(...).protect is not a function
@ChristianIvicevic @cbmastery Could you share any more details on the codemod failures you encountered?
Latest canary breaks the middleware, specifically auth().protect() in clerkMiddleware
middleware.js (17:12) @ TURBOPACK__default__export.debug TypeError: auth(...).protect is not a function
If you read the changes thoroughly you'll notice that it's await auth.protect()
now and not auth().protect()
.
@jacekradko Yesterday I attempted to run pnpm dlx @clerk/upgrade@1.1.0-canary.va0204a8
and the CLI recognized I was using the Next.js SDK but then did not apply any changes at all without any additional output. Is this the intended way to invoke the CLI in the first place? Just to make sure it's not an error on my end.
Latest canary breaks the middleware, specifically auth().protect() in clerkMiddleware
middleware.js (17:12) @ TURBOPACK__default__export.debug TypeError: auth(...).protect is not a function
if you're using "@clerk/nextjs": "^6.0.0",
just change auth().protect() to this.
export default clerkMiddleware(async (auth, request) => {
const { userId, redirectToSignIn } = await auth();
if (!userId && isPublicRoute(request)) {
// Add custom logic to run before redirecting
return redirectToSignIn();
}
});```
@ChristianIvicevic I am running exactly what is in the documentation on clerk website for next.js and have tried applying the mention async solution by @fprado-dev as well but once I import isPublicRoute it throws an error. I also have a an app/auth/sign-in[[...sign-in]] and a sign-up[[...sign-up]] folders that are .tsx files, would those need to be async?Apologies, am noob. :)
@ChristianIvicevic I am running exactly what is in the documentation on clerk website for next.js and have tried applying the mention async solution by @fprado-dev as well but once I import isPublicRoute it throws an error. I also have a an app/auth/sign-in[[...sign-in]] and a sign-up[[...sign-up]] folders that are .tsx files, would those need to be async?Apologies, am noob. :)
import { clerkMiddleware, createRouteMatcher } from "@clerk/nextjs/server";
const isPublicRoute = createRouteMatcher(["/auth/sign-in(.)", "/auth/sign-up(.)"]);
your file must be page.tsx.
if doesnโt work try to upgrade your next to 15.0.1 and @clerk/nextjs": "^6.0.0"
if you need help leet me know, show me which error that its throws maybe i can help you