clerk/javascript

clerk not compatible nextjs 15

Closed this issue ยท 16 comments

Preliminary Checks

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",
image

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

eifo commented

Clerk provider not awaiting headers throws error per @clerk/nextjs": "^5.7.5" and "next": "^15.0.1-canary.1" next --turbo.

@eifo As drosi pointed out, the fix is part of #4366 and will most likely be shipped in a major update anytime soon.

eifo commented

@eifo As drosi pointed out, the fix is part of #4366 and will most likely be shipped in a major update anytime soon.

This got worst with latest next canary, it's critical at this point.

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...?

eifo commented

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