The Next.js team has announced the stable release of Next.js 15, and Clerk is continuing the tradition of (nearly) same-day support for new major Next.js releases with the release of @clerk/nextjs v6.
Get started by running the Clerk upgrade CLI:
Not ready to upgrade to Next.js v15? No problem: @clerk/nextjs v6 is backwards compatible with Next.js v14, including the switch to static rendering by default.
auth() (breaking change)Now that Next.js's request APIs are asynchronous, Clerk's auth() helper will follow suit. In addition to supporting Next.js's new async APIs, this change will also allow the addition of more robust validations and new functionality into the auth() helper. Stay tuned!
With the change to async, we weren't happy with how the usage of auth().protect() felt, so we moved protect to be a property of auth, instead of part of the return value.
To make migration as easy as possible, we're also including a codemod that will update your usages of auth() and auth().protect(). For situations where the codemod isn't able to update your code, please see the upgrade guide for detailed steps.
Historically, usage of <ClerkProvider> has opted your entire application in to dynamic rendering due to the dynamic and personalized nature of auth-related data. We've heard the feedback from our users that this default didn't feel like it aligned with Next.js best practices. Starting with v6, <ClerkProvider> will no longer opt your entire application into dynamic rendering by default. This change also brings support for Next.js's upcoming Partial Prerendering mode (PPR). PPR allows a page to be both static and dynamic by moving the optimization from pages to components.
Dynamic auth data is still available by using the auth() helper in a server component. This data can also be passed to client components directly as needed. This is the recommended way to access auth data going forward. For existing applications that use the useAuth() hook in Client Components that are server-side rendered, this is a breaking change. Wrap these components in <ClerkProvider dynamic> to make auth data available to the hook during rendering. As a best practice, we recommend wrapping usage of <ClerkProvider dynamic> with suspense to ensure your page is setup to take advantage of PPR.
If you want <ClerkProvider> to continue making dynamic auth data available by default, add the dynamic prop to your root <ClerkProvider>:
This opts every single page into dynamic rendering, or PPR when enabled. For this reason, it is still recommended to take a more granular approach to dynamic data access by using <ClerkProvider dynamic> further down your component tree.
To learn more about Next.js's different rendering modes and how Clerk interacts with them, check out the documentation.
A number of deprecated APIs have been removed as part of this release:
authMiddleware() - use clerkMiddleware() insteadredirectToSignIn() - use const { redirectToSignIn } = await auth() insteadredirectToSignUp() - use const { redirectToSignUp } = await auth() insteadclerkClient singleton - use await clerkClient() insteadFor more information, please see the upgrade guide.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。