@clerk/upgrade 1.0.2 → 1.0.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (24) hide show
  1. package/dist/guide-generators/core-2/backend/__output.mdx +687 -0
  2. package/dist/guide-generators/core-2/chrome-extension/__output.mdx +530 -0
  3. package/dist/guide-generators/core-2/expo/__output.mdx +546 -0
  4. package/dist/guide-generators/core-2/fastify/__output.mdx +448 -0
  5. package/dist/guide-generators/core-2/gatsby/__output.mdx +503 -0
  6. package/dist/guide-generators/core-2/js/__output.mdx +628 -0
  7. package/dist/guide-generators/core-2/nextjs/__output.mdx +1169 -0
  8. package/dist/guide-generators/core-2/node/__output.mdx +592 -0
  9. package/dist/guide-generators/core-2/overview/__output.mdx +33 -0
  10. package/dist/guide-generators/core-2/overview/intro.mdx +1 -1
  11. package/dist/guide-generators/core-2/react/__output.mdx +790 -0
  12. package/dist/guide-generators/core-2/remix/__output.mdx +432 -0
  13. package/dist/guide-generators/core-2/retheme/__output.mdx +440 -0
  14. package/dist/guide-generators/core-2/shared/prepare.mdx +0 -5
  15. package/dist/guide-generators/core-2/shared/update-version.mdx +5 -5
  16. package/dist/versions/core-2/backend/members-count.md +2 -2
  17. package/dist/versions/core-2/index.js +1 -1
  18. package/dist/versions/core-2/nextjs/auth-middleware-deprecated.md +2 -2
  19. package/dist/versions/core-2/nextjs/authmiddleware-import-change.md +1 -1
  20. package/dist/versions/core-2/nextjs/with-clerk-middleware-removed.md +1 -1
  21. package/dist/versions/core-2/node/createclerkexpressrequireauth-public-key-required.md +2 -2
  22. package/dist/versions/core-2/node/createclerkexpresswithauth-publickey-required.md +7 -0
  23. package/package.json +1 -1
  24. /package/dist/versions/core-2/{js/supported-external-accounts-type-removed.md → common/supported-external-accounts-removed.md} +0 -0
@@ -0,0 +1,1169 @@
1
+ ---
2
+ title: "Upgrading Next.js to Core 2"
3
+ description: "Learn how to upgrade Clerk's Next.js SDK to the latest version."
4
+ ---
5
+
6
+ {/* WARNING: This is a generated file and should not be edited directly. To update its contents, see the "upgrade" package in the clerk/javascript repo. */}
7
+
8
+ # Upgrading `@clerk/nextjs` to Core 2
9
+
10
+ Core 2 is included in the Next.js SDK starting with version 5.0.0. This new version ships with an improved design and UX for its built-in components, no "flash of white page" when authenticating, a substantially improved middleware import, and a variety of smaller DX improvements and housekeeping items. Each of the potentially breaking changes are detailed in this guide, below.
11
+
12
+ By the end of this guide, you’ll have successfully upgraded your Next.js project to use `@clerk/nextjs` v5. You’ll learn how to update your dependencies, resolve breaking changes, and find deprecations. Step-by-step instructions will lead you through the process.
13
+
14
+ ## Preparing to upgrade
15
+
16
+ Before uprading, it's highly recommended that you update your Clerk SDKs to the latest Core 1 version (`npm i @clerk/nextjs@4`). Some changes required for Core 2 SDKs can be applied incrementally to the v5 release, which should contribute to a smoother upgrading experience. After updating, look out for deprecation messages in your terminal and browser console. By resolving these deprecations you'll be able to skip many breaking changes from Core 2.
17
+
18
+ Additionally, some of the minumum version requirements for some base dependencies have been updated such that versions that are no longer supported or are at end-of-life are no longer guaranteed to work correctly with Clerk.
19
+
20
+ **Updating Node.js**
21
+
22
+ You need to have Node.js `18.17.0` or later installed. Last year, Node.js 16 entered EOL (End of life) status, so support for this version has been removed across Clerk SDKs. You can check your Node.js version by running `node -v` in your terminal. Learn more about how to [update and install Node.js](https://nodejs.org/en/learn/getting-started/how-to-install-nodejs).
23
+
24
+ **Updating React**
25
+
26
+ All react-dependent Clerk SDKs now require you to use React 18 or higher. You can update your project by installing the latest version of `react` and `react-dom`.
27
+
28
+ <CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
29
+ ```bash filename="terminal"
30
+ npm install react@latest react-dom@latest
31
+ ```
32
+
33
+ ```bash filename="terminal"
34
+ yarn add react@latest react-dom@latest
35
+ ```
36
+
37
+ ```bash filename="terminal"
38
+ pnpm add react@latest react-dom@latest
39
+ ```
40
+
41
+ </CodeBlockTabs>
42
+
43
+ If you are upgrading from React 17 or lower, make sure to [learn about how to upgrade your React version to 18](https://react.dev/blog/2022/03/08/react-18-upgrade-guide) as well.
44
+
45
+ **Updating Next.js**
46
+
47
+ `@clerk/nextjs` now requires you to use Next.js version `13.0.4` or later. Check out Next's upgrade guides for more guidance if you have not yet upgraded to Next.js 13:
48
+
49
+ - [Upgrading from 12 to 13](https://nextjs.org/docs/pages/building-your-application/upgrading/version-13)
50
+ - [Upgrading from 13 to 14](https://nextjs.org/docs/app/building-your-application/upgrading/version-14)
51
+
52
+ ## Updating to Core 2
53
+
54
+ Whenever you feel ready, go ahead and install the latest version of any Clerk SDKs you are using. Make sure that you are prepared to patch some breaking changes before your app will work properly, however. The commands below demonstrate how to install the latest version.
55
+
56
+ <CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
57
+ ```bash filename="terminal"
58
+ npm install @clerk/nextjs
59
+ ```
60
+
61
+ ```bash filename="terminal"
62
+ yarn add @clerk/nextjs
63
+ ```
64
+
65
+ ```bash filename="terminal"
66
+ pnpm add @clerk/nextjs
67
+ ```
68
+
69
+ </CodeBlockTabs>
70
+
71
+ ## CLI upgrade helper
72
+
73
+ Clerk now provides a `@clerk/upgrade` CLI tool that you can use to ease the upgrade process. The tool will scan your codebase and produce a list of changes you'll need to apply to your project. It should catch the vast majority of the changes needed for a successful upgrade to any SDK including Core 2. This can save you a lot of time reading through changes that don't apply to your project.
74
+
75
+ To run the CLI tool, navigate to your project and run it in the terminal:
76
+
77
+ <CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
78
+ ```bash filename="terminal"
79
+ npx @clerk/upgrade
80
+ ```
81
+
82
+ ```bash filename="terminal"
83
+ yarn dlx @clerk/upgrade
84
+ ```
85
+
86
+ ```bash filename="terminal"
87
+ pnpm dlx @clerk/upgrade
88
+ ```
89
+
90
+ </CodeBlockTabs>
91
+
92
+ If you are having trouble with `npx`, it's also possible to install directly with `npm i @clerk/upgrade -g`, and can then be run with the `clerk-upgrade` command.
93
+
94
+ ## Breaking Changes
95
+
96
+ ### Component design adjustments
97
+
98
+ The new version ships with improved design and UX across all of Clerk's [UI components](/docs/components/overview). If you have used the [`appearance` prop](/docs/components/customization/overview) or tokens for a [custom theme](/docs/components/customization/overview#create-a-custom-theme), you will likely need to make some adjustments to ensure your styling is still looking great. If you're using the [localization prop](/docs/components/customization/localization) you will likely need to make adjustments to account for added or removed localization keys.
99
+
100
+ [More detail on these changes &raquo;](component-redesign)
101
+
102
+ ### New Middleware architecture
103
+
104
+ User and customer feedback about `authMiddleware()` has been clear in that Middleware logic was a often friction point. As such, in v5 you will find a completely new Middleware helper called [`clerkMiddleware()`](/docs/references/nextjs/clerk-middleware) that should alleviate the issues folks had with `authMiddleware()`.
105
+
106
+ The primary change from the previous `authMiddleware()` is that `clerkMiddleware()` does not protect any routes by default, instead requiring the developer to add routes they would like to be protected by auth. This is a substantial contrast to the previous `authMiddleware()`, which protected all routes by default, requiring the developer to add exceptions. The API was also substantially simplified, and it has become easier to combine with other Middleware helpers smoothly as well.
107
+
108
+ Here's an example that demonstrates route protection based on both authentication and authorization:
109
+
110
+ ```ts filename="middleware.ts"
111
+ import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';
112
+
113
+ const isDashboardRoute = createRouteMatcher(['/dashboard(.*)']);
114
+ const isAdminRoute = createRouteMatcher(['/admin(.*)']);
115
+
116
+ export default clerkMiddleware((auth, req) => {
117
+ // Restrict admin route to users with specific role
118
+ if (isAdminRoute(req)) auth().protect({ role: 'org:admin' });
119
+
120
+ // Restrict dashboard routes to logged in users
121
+ if (isDashboardRoute(req)) auth().protect();
122
+ });
123
+
124
+ export const config = {
125
+ matcher: ['/((?!.*\\..*|_next).*)', '/', '/(api|trpc)(.*)'],
126
+ };
127
+ ```
128
+
129
+ A couple things to note here:
130
+
131
+ - The `createRouteMatcher` helper makes it easy to define route groups that you can leverage inside the Middleware function and check in whichever order you'd like. Note that it can take an array of routes as well.
132
+ - With `clerkMiddleware`, you're defining the routes you want **to be protected**, rather than the routes you don't want to be protected.
133
+ - The [`auth().protect()`](https://clerk.com/docs/references/nextjs/auth#protect) helper is utilized heavily here, check out its docs for more info.
134
+
135
+ See the [`clerkMiddleware()`](/docs/references/nextjs/clerk-middleware) docs for more information and detailed usage examples.
136
+
137
+ #### Migrating to `clerkMiddleware()`
138
+
139
+ Clerk strongly recommends migrating to the new `clerkMiddleware()` for an improved DX and access to all present and upcoming features, but also want to note that `authMiddleware()`, while deprecated, will continue to work in v5 and will not be removed until the next major version, so you do not _need_ to make any changes to your Middleware setup this version.
140
+
141
+ The most basic migration will be updating the import and changing out the default export, then mirroring the previous behavior of protecting all routes as such:
142
+
143
+ ```diff
144
+ - import { authMiddleware } from "@clerk/nextjs"
145
+ + import { clerkMiddleware } from '@clerk/nextjs/server'
146
+
147
+ - export default authMiddleware()
148
+ + export default clerkMiddleware((auth) => auth().protect())
149
+
150
+ export const config = {
151
+ matcher: ["/((?!.*\\..*|_next).*)", "/", "/(api|trpc)(.*)"],
152
+ }
153
+ ```
154
+
155
+ Of course, in most cases you'll have a more complicated setup than this. You can find some examples below for how to migrate a few common use cases. Be sure to review the [`clerkMiddleware()` documentation](/docs/references/nextjs/clerk-middleware) if your specific use case is not mentioned.
156
+
157
+ <Accordion titles={["Protecting all routes except one or more public paths", "Protecting a single route path", "Combining with other Middlewares (like i18n)", "Using the redirectToSignIn method"]} heading="h4">
158
+ <AccordionPanel>
159
+ By default, `clerkMiddleware()` treats all pages as public unless explicitly protected. If you prefer for it to operate the other way around (all pages are protected unless explicitly made public), you can reverse the middleware logic in this way:
160
+
161
+ Before:
162
+
163
+ ```ts filename="middleware.ts"
164
+ import { authMiddleware } from "@clerk/nextjs"
165
+
166
+ export default authMiddleware({
167
+ publicRoutes: ["/", "/contact"],
168
+ })
169
+
170
+ export const config = {
171
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
172
+ }
173
+ ```
174
+
175
+ After:
176
+
177
+ ```ts filename="middleware.ts"
178
+ import {
179
+ clerkMiddleware,
180
+ createRouteMatcher
181
+ } from "@clerk/nextjs/server"
182
+
183
+ const isPublicRoute = createRouteMatcher(["/", "/contact"])
184
+
185
+ export default clerkMiddleware((auth, req) => {
186
+ if (isPublicRoute(req)) return // if it's a public route, do nothing
187
+ auth().protect() // for any other route, require auth
188
+ })
189
+
190
+ export const config = {
191
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
192
+ }
193
+ ```
194
+
195
+ </AccordionPanel>
196
+ <AccordionPanel>
197
+ An example can be seen below of code that ensures that all routes are public except everything under `/dashboard`.
198
+
199
+ Before:
200
+
201
+ ```ts filename="middleware.ts"
202
+ import { authMiddleware } from "@clerk/nextjs"
203
+
204
+ export default authMiddleware({
205
+ publicRoutes: (req) => !req.url.includes("/dashboard"),
206
+ })
207
+
208
+ export const config = {
209
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
210
+ }
211
+ ```
212
+
213
+ After:
214
+
215
+ ```ts filename="middleware.ts"
216
+ import {
217
+ clerkMiddleware,
218
+ createRouteMatcher
219
+ } from "@clerk/nextjs/server"
220
+
221
+ const isDashboardRoute = createRouteMatcher(["/dashboard(.*)"])
222
+
223
+ export default clerkMiddleware((auth, request) => {
224
+ if (isDashboardRoute(request)) auth().protect()
225
+ })
226
+
227
+ export const config = {
228
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
229
+ }
230
+ ```
231
+
232
+ </AccordionPanel>
233
+ <AccordionPanel>
234
+ You can call other Middlewares inside `clerkMiddleware()`, giving you more direct control over what is called where. An example would be [next-intl](https://next-intl-docs.vercel.app/) to add internationalization to your app.
235
+
236
+ Before:
237
+
238
+ ```ts filename="middleware.ts"
239
+ import { authMiddleware } from "@clerk/nextjs"
240
+ import createMiddleware from "next-intl/middleware"
241
+
242
+ const intlMiddleware = createMiddleware({
243
+ locales: ["en", "de"],
244
+ defaultLocale: "en",
245
+ })
246
+
247
+ export default authMiddleware({
248
+ beforeAuth: (req) => {
249
+ return intlMiddleware(req);
250
+ },
251
+ publicRoutes: ["((?!^/dashboard/).*)"],
252
+ })
253
+
254
+ export const config = {
255
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
256
+ }
257
+ ```
258
+
259
+ After:
260
+
261
+ ```ts filename="middleware.ts"
262
+ import {
263
+ clerkMiddleware,
264
+ createRouteMatcher
265
+ } from "@clerk/nextjs/server"
266
+ import createMiddleware from "next-intl/middleware"
267
+
268
+ const intlMiddleware = createMiddleware({
269
+ locales: ["en", "de"],
270
+ defaultLocale: "en",
271
+ })
272
+
273
+ const isDashboardRoute = createRouteMatcher(["/dashboard(.*)"])
274
+
275
+ export default clerkMiddleware((auth, request) => {
276
+ if (isDashboardRoute(request)) auth().protect()
277
+
278
+ return intlMiddleware(request)
279
+ })
280
+
281
+ export const config = {
282
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
283
+ }
284
+ ```
285
+
286
+ </AccordionPanel>
287
+ <AccordionPanel>
288
+ You can now access `redirectToSignIn` from the `auth()` object, rather than importing at the top level.
289
+
290
+ Before:
291
+
292
+ ```ts filename="middleware.ts"
293
+ import { authMiddleware, redirectToSignIn } from "@clerk/nextjs"
294
+
295
+ export default authMiddleware({
296
+ if (someCondition) redirectToSignIn()
297
+ })
298
+
299
+ export const config = {
300
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
301
+ }
302
+ ```
303
+
304
+ After:
305
+
306
+ ```ts filename="middleware.ts"
307
+ import { clerkMiddleware } from "@clerk/nextjs/server"
308
+
309
+ export default clerkMiddleware((auth, req) => {
310
+ if (someCondition) auth().redirectToSignIn()
311
+ })
312
+
313
+ export const config = {
314
+ matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
315
+ }
316
+ ```
317
+
318
+ </AccordionPanel>
319
+ </Accordion>
320
+
321
+ ### Changes to top-level exports
322
+
323
+ As part of this release, some of the top-level exports of `@clerk/nextjs` have been changed in order to improve bundle size and tree-shaking efficiency. These changes have resulted in a ~75% reduction in build size for middleware bundles. However, you will likely need to make some changes to import paths as a result.
324
+
325
+ <Callout type='info'>
326
+ Use [the CLI tool](#cli-upgrade-helper) to automatically find occurences of imports that need to be changed.
327
+ </Callout>
328
+
329
+ <Accordion titles={["@clerk/nextjs/server", "@clerk/nextjs/errors", "@clerk/nextjs/app-beta", "@clerk/nextjs/ssr", "@clerk/nextjs/edge-middleware", "@clerk/nextjs/edge-middlewarefiles", "@clerk/nextjs/api"]}>
330
+ <AccordionPanel>
331
+ Previously these exports have been exported both from `@clerk/nextjs` and `@clerk/nextjs/server`. As of v5 they are only exported from the latter. Going forward, the expectation can be that any imports that are intended to run within react on the client side, will come from `@clerk/nextjs` and imports that are intended to run on the server, will come from `@clerk/nextjs/server`.
332
+
333
+ ```diff
334
+ import {
335
+ auth,
336
+ currentUser,
337
+ authMiddleware,
338
+ buildClerkProps,
339
+ verifyToken,
340
+ verifyJwt,
341
+ decodeJwt,
342
+ signJwt,
343
+ constants,
344
+ redirect,
345
+ createAuthenticateRequest,
346
+ createIsomorphicRequest,
347
+ - } from "@clerk/nextjs"
348
+ + } from "@clerk/nextjs/server"
349
+ ```
350
+
351
+ </AccordionPanel>
352
+ <AccordionPanel>
353
+ Exports related to errors are now under `@clerk/nextjs/errors`.
354
+
355
+ ```diff
356
+ import {
357
+ isClerkAPIResponseError,
358
+ isEmailLinkError,
359
+ isKnownError,
360
+ isMetamaskError,
361
+ EmailLinkErrorCode,
362
+ - } from "@clerk/nextjs"
363
+ + } from "@clerk/nextjs/errors"
364
+ ```
365
+
366
+ </AccordionPanel>
367
+ <AccordionPanel>
368
+ The `@clerk/nextjs` import will work with both the app and pages router.
369
+
370
+ ```diff
371
+ - import { } from "@clerk/nextjs/app-beta"
372
+ + import { } from "@clerk/nextjs"
373
+ ```
374
+
375
+ Some behavior may have changed between Clerk's beta and the stable release. Please check on your end if behavior stayed the same.
376
+
377
+ </AccordionPanel>
378
+ <AccordionPanel>
379
+ The top-level exports support SSR by default now.
380
+
381
+ ```diff
382
+ - import { } from "@clerk/nextjs/ssr"
383
+ + import { } from "@clerk/nextjs"
384
+ ```
385
+
386
+ </AccordionPanel>
387
+ <AccordionPanel>
388
+ ```diff
389
+ - import { } from "@clerk/nextjs/edge-middleware"
390
+ + import { } from "@clerk/nextjs"
391
+ ```
392
+ </AccordionPanel>
393
+ <AccordionPanel>
394
+ ```diff
395
+ - import { } from "@clerk/nextjs/edge-middlewarefiles"
396
+ + import { } from "@clerk/nextjs"
397
+ ```
398
+ </AccordionPanel>
399
+ <AccordionPanel>
400
+ The `@clerk/nextjs/api` subpath was removed completely. It re-exported helpers from `@clerk/clerk-sdk-node` and its types. If you relied on these, import from `@clerk/clerk-sdk-node` directly instead.
401
+
402
+ ```diff
403
+ import type {
404
+ ClerkMiddleware,
405
+ ClerkMiddlewareOptions,
406
+ LooseAuthProp,
407
+ RequireAuthProp,
408
+ StrictAuthProp,
409
+ WithAuthProp
410
+ - } from "@clerk/nextjs/api"
411
+ + } from "@clerk/clerk-sdk-node"
412
+
413
+ - import { requireAuth, withAuth } from "@clerk/nextjs/api"
414
+ + import { requireAuth, withAuth } from "@clerk/clerk-sdk-node"
415
+ ```
416
+
417
+ </AccordionPanel>
418
+ </Accordion>
419
+
420
+ ### After sign up/in/out default value change
421
+
422
+ Defining redirect URLs for after sign up, in, and/or out via the Clerk dashboard has been removed in Core 2. In your Clerk dashboard, under "paths", there is a section called "Component paths", where URLs could be defined that had a deprecation warning. In Core 2, this functionality has been removed, and specifying redirect paths via the dashboard will no longer work. If you need to pass a redirect URL for after sign in/up/out, there are [a few different ways this can be done](https://clerk.com/docs/account-portal/custom-redirects), from environment variables to middleware to supplying them directly to the relevant components.
423
+
424
+ As part of this change, the default URL for each of these props has been set to `/`, so if you are passing `/` explicitly to any one of the above props, that line is no longer necessary and can be removed.
425
+
426
+ ```diff
427
+ - <UserButton afterSignOutUrl='/' />
428
+ + <UserButton />
429
+ ```
430
+
431
+ ### `afterSignXUrl` changes
432
+
433
+ Some changes are being made to the way that "after sign up/in url"s and redirect url props are handled as part of this new version, in order to make behavior more clear and predictable.
434
+
435
+ > We will refer to these urls as `afterSignXUrl` where `X` could be `Up` or `In` depending on the context.
436
+
437
+ Previously, setting `afterSignInUrl` or `afterSignOutUrl` would only actually redirect some of the time. If the user clicks on any form of link that takes them to a sign up/in page, Clerk automatically sets `redirect_url` in the querystring such that after the sign up or in, the user is returned back to the page they were on before. This is a common pattern for sign up/in flows, as it leads to the least interruption of the user's navigation through your app. When a `redirect_url` is present, any value passed to `afterSignInUrl` or `afterSignUpUrl` is ignored. However, if the user navigates directly to a sign up/in page, there’s no redirect url in the querystring and in this case the `afterSignInUrl` or `afterSignOutUrl` would take effect. This behavior was not intuitive and didn't give a way to force a redirect after sign up/in, so the behavior is changing to address both of these issues.
438
+
439
+ All `afterSignXUrl` props and `CLERK_AFTER_SIGN_X_URL` environment variables have been removed, and should be replaced by one of the following options:
440
+
441
+ - `signXForceRedirectUrl` / `CLERK_SIGN_X_FORCE_REDIRECT_URL` - if set, Clerk will always redirect to provided URL, regardless of what page the user was on before. Use this option with caution, as it will interrupt the user’s flow by taking them away from the page they were on before.
442
+ - `signXFallbackRedirectUrl` / `CLERK_SIGN_UP_FALLBACK_REDIRECT_URL` - if set, this will mirror the previous behavior, only redirecting to the provided URL if there is no `redirect_url` in the querystring.
443
+
444
+ If neither value is set, Clerk will redirect to the `redirect_url` if present, otherwise it will redirect to `/`. If you'd like to retain the current behavior of your app without any changes, you can switch `afterSignXUrl` with `signXFallbackRedirectUrl` as such:
445
+
446
+ ```diff
447
+ - <SignIn afterSignInUrl='/foo' />
448
+ + <SignIn signInFallbackRedirectUrl='/foo' />
449
+ ```
450
+
451
+ ### Removed: `orgs` claim on JWT
452
+
453
+ In the previous version of Clerk's SDKs, if you decode the session token that Clerk returns from the server, you'll currently find an `orgs` claim on it. It lists all the orgs associated with the given user. Now, Clerk returns the `org_id`, `org_slug`, and `org_role` of the **active** organization.
454
+
455
+ The `orgs` claim was part of the `JwtPayload`. Here are a few examples of where the `JwtPayload` could be found.
456
+
457
+ <Accordion titles={["Next.js", "Fastify", "@clerk/backend", "@clerk/clerk-sdk-node"]} heading="h5">
458
+ <AccordionPanel>
459
+ ```typescript filename="Next.js"
460
+ import { getAuth } from "@clerk/nextjs/server"
461
+ const claims: JwtPayload = getAuth(request).sessionClaims
462
+
463
+ import { getAuth } from "@clerk/ssr.server"
464
+ const claims: JwtPayload = (await getAuth(request)).sessionClaims
465
+ ```
466
+
467
+ </AccordionPanel>
468
+ <AccordionPanel>
469
+ ```typescript filename="Fastify"
470
+ import { getAuth } from "@clerk/fastify"
471
+ const claims: JwtPayload = (await getAuth(request)).sessionClaims
472
+ ```
473
+ </AccordionPanel>
474
+ <AccordionPanel>
475
+ ```typescript filename="@clerk/backend"
476
+ import { createClerkClient } from "@clerk/backend"
477
+
478
+ const clerkClient = createClerkClient({ secretKey: "" })
479
+ const requestState = await clerkClient.authenticateRequest(
480
+ request,
481
+ { publishableKey: "" }
482
+ )
483
+ const claims: JwtPayload = requestState.toAuth().sessionClaims
484
+ ```
485
+
486
+ </AccordionPanel>
487
+ <AccordionPanel>
488
+ ```typescript filename="@clerk/clerk-sdk-node"
489
+ import { clerkClient } from "@clerk/clerk-sdk-node"
490
+
491
+ router.use((...args) => clerkClient.expressRequireAuth()(...args))
492
+ router.get("/me", async (req, reply: Response) => {
493
+ return reply.json({ auth: req.auth })
494
+ })
495
+ ```
496
+
497
+ </AccordionPanel>
498
+ </Accordion>
499
+
500
+ If you would like to have your JWT return all of the user's organizations, you can create a [custom JWT template](/docs/backend-requests/making/jwt-templates) in your dashboard. Add `{ "orgs": "user.organizations" }` to it.
501
+
502
+ ### Path routing is now the default
503
+
504
+ On components like [`<SignIn />`](/docs/components/authentication/sign-in) you can define the props `routing` and `path`. `routing` can be set to `'hash' | 'path' | 'virtual'` and describes the routing strategy that should be used. `path` defines where the component is mounted when `routing="path"` is used.
505
+
506
+ In the latest version, the **default** `routing` strategy has become `'path'`. Unless you change the `routing` prop, you'll need to define the `path` prop. The affected components are:
507
+
508
+ - `<SignIn />`
509
+ - `<SignUp />`
510
+ - `<UserProfile />`
511
+ - `<CreateOrganization />`
512
+ - `<OrganizationProfile />`
513
+
514
+ Here's how you'd use the components going forward:
515
+
516
+ ```jsx
517
+ <SignIn path="/sign-in" />
518
+ <SignUp path="/sign-up" />
519
+ <UserProfile path="/user-profile" />
520
+ <CreateOrganization path="/create-org" />
521
+ <OrganizationProfile path="/org-profile" />
522
+ ```
523
+
524
+ If you don't define the `path` prop an error will be thrown. Of course, you can still use `routing="hash"` or `routing="virtual"`.
525
+
526
+ ```jsx
527
+ <UserProfile routing="hash" />
528
+ <OrganizationProfile routing="virtual" />
529
+ ```
530
+
531
+
532
+ For the @clerk/nextjs SDK, you can set environment variables for the sign up/in URLs and avoid needing to explicitly pass the path to the `<SignIn />` and `<SignUp />` components.
533
+
534
+
535
+
536
+ ```env filename=".env.local"
537
+ NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
538
+ NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up
539
+ ```
540
+
541
+
542
+
543
+
544
+ If you have defined both environment variables, you're able to use the `<SignIn />` and `<SignUp />` components without any props, as such:
545
+
546
+ ```jsx
547
+ <SignIn />
548
+ <SignUp />
549
+ ```
550
+
551
+
552
+
553
+ ### Image URL Name Consolidation
554
+
555
+ There are a number of Clerk primitives that contain images, and previously they each had different property names, like `avatarUrl`, `logoUrl`, `profileImageUrl`, etc. In order to promote consistency and make it simpler for developers to know where to find associated images, all image properties are now named `imageUrl`. See the list below for all affected classes:
556
+
557
+ <Accordion titles={["<code>Organization.logoUrl</code> -&gt; <code>Organization.imageUrl</code>", "<code>User.profileImageUrl</code> -&gt; <code>.imageUrl</code>", "<code>ExternalAccount.avatarUrl</code> -&gt; <code>.imageUrl</code>", "<code>OrganizationMembershipPublicUserData.profileImageUrl</code> -&gt; <code>.imageUrl</code>"]}>
558
+ <AccordionPanel>
559
+ The `logoUrl` property of any [`Organization` object](https://clerk.com/docs/references/javascript/organization/organization#organization) has been changed to `imageUrl`.
560
+ </AccordionPanel>
561
+ <AccordionPanel>
562
+ The `profileImageUrl` property of any `User` object has been changed to `imageUrl`.
563
+ </AccordionPanel>
564
+ <AccordionPanel>
565
+ The `avatarUrl` property of any [`ExternalAcccount` object](https://clerk.com/docs/references/javascript/external-account) has been changed to `imageUrl`.
566
+ </AccordionPanel>
567
+ <AccordionPanel>
568
+ The `profileImageUrl` property of any `OrganizationMembershipPublicUserData` object has been changed to `imageUrl`.
569
+ </AccordionPanel>
570
+ </Accordion>
571
+
572
+ ### Deprecation removals & housekeeping
573
+
574
+ As part of this major version, a number of previously deprecated props, arugments, methods, etc. have been removed. Additionally there have been some changes to things that are only used internally, or only used very rarely. It's highly unlikely that any given app will encounter any of these items, but they are all breaking changes, so they have all been documented below.
575
+
576
+ <Callout type='info'>
577
+ For this section more than any other one, please use the CLI upgrade tool (`npx @clerk/upgrade`). Changes in this
578
+ section are very unlikely to appear in your codebase, the tool will save time looking for them.
579
+ </Callout>
580
+
581
+ #### Deprecation removals
582
+
583
+ <Accordion titles={["<code>User.update({ password: &#39;x&#39; })</code> -&gt; <code>User.updatePassword(&#39;x&#39;)</code>", "<code>CLERK_API_KEY</code> replaced by <code>CLERK_SECRET_KEY</code>", "<code>CLERK_FRONTEND_API</code> replaced by <code>CLERK_PUBLISHABLE_KEY</code>", "<code>CLERK_JS_VERSION</code> should be <code>NEXT_PUBLIC_CLERK_JS_VERSION</code>", "<code>apiKey</code> -&gt; <code>secretKey</code> as param to <code>authMiddleware</code>", "<code>frontendApi</code> -&gt; <code>publishableKey</code> as param to <code>authMiddleware</code>", "<code>apiKey</code> -&gt; <code>secretKey</code> as param to <code>createClerkClient</code>", "<code>frontendApi</code> -&gt; <code>publishableKey</code> as param to <code>createClerkClient</code>", "<code>apiKey</code> -&gt; <code>secretKey</code> as param to <code>getAuth</code>", "<code>frontendApi</code> -&gt; <code>publishableKey</code> as prop to <code>ClerkProvider</code>", "<code>@clerk/nextjs/app-beta</code> import removed", "<code>@clerk/nextjs/ssr</code> import removed", "<code>@clerk/nextjs/edge-middleware</code> import removed", "<code>@clerk/nextjs/edge-middlewarefiles</code> import removed", "<code>API_URL</code> constant removed", "<code>API_VERSION</code> constant removed", "<code>CLERK_JS_URL</code> constant removed", "<code>CLERK_JS_VERSION</code> constant removed", "<code>DOMAIN</code> constant removed", "<code>IS_SATELLITE</code> constant removed", "<code>PROXY_URL</code> constant removed", "<code>PUBLISHABLE_KEY</code> constant removed", "<code>SECRET_KEY</code> constant removed", "<code>SIGN_IN_URL</code> constant removed", "<code>SIGN_UP_URL</code> constant removed", "<code>@clerk/nextjs/api</code> import removed", "<code>MultiSessionAppSupport</code> import moved under <code>/internal</code>", "<code>NEXT_PUBLIC_CLERK_JS</code> should be <code>NEXT_PUBLIC_CLERK_JS_URL</code>"]}>
584
+ <AccordionPanel>
585
+ If you are updating a user's password via the [`User.update` method](https://clerk.com/docs/references/javascript/user/user#update), it must be changed to [`User.updatePassword`](https://clerk.com/docs/references/javascript/user/password-management#update-password) instead. This method will require the current password as well as the desired new password. We made this update to improve the security of password changes. Example below:
586
+
587
+ ```diff
588
+ - user.update({ password: 'foo' });
589
+
590
+ + user.updatePassword({
591
+ + currentPassword: 'bar',
592
+ + newPassword: 'foo',
593
+ + signOutOfOtherSessions: true,
594
+ + });
595
+ ```
596
+ </AccordionPanel>
597
+ <AccordionPanel>
598
+ The `CLERK_API_KEY` environment variable was renamed to `CLERK_SECRET_KEY`. You can visit your [Clerk dashboard](https://dashboard.clerk.com/last-active?path=api-keys) to copy/paste the new keys after choosing your framework. Make sure to update this in all environments (e.g. dev, staging, production).
599
+ </AccordionPanel>
600
+ <AccordionPanel>
601
+ The `CLERK_FRONTEND_API` environment variable was renamed to `CLERK_PUBLISHABLE_KEY`. You can visit your [Clerk dashboard](https://dashboard.clerk.com/last-active?path=api-keys) to copy/paste the new keys after choosing your framework. Make sure to update this in all environments (e.g. dev, staging, production). **Note:** The values are different, so this is not just a key replacement. [More information](/docs/deployments/overview#api-keys-and-environment-variables).
602
+ </AccordionPanel>
603
+ <AccordionPanel>
604
+ If you are using `CLERK_JS_VERSION` as an environment variable, it should be changed to `NEXT_PUBLIC_CLERK_JS_VERSION` instead.
605
+
606
+ This change brings our SDK up to date with the latest standards for next.js - that public environment variables should have the `NEXT_PUBLIC_` prefix. This env variable is not private, so it should get the public prefix.
607
+ </AccordionPanel>
608
+ <AccordionPanel>
609
+ The `apiKey` argument passed to `authMiddleware` must be changed to `secretKey`.
610
+
611
+ ```diff
612
+ import { authMiddleware } from '@clerk/nextjs';
613
+
614
+ - authMiddleware({ apiKey: '...' });
615
+ + authMiddleware({ secretKey: '...' });
616
+ ```
617
+ </AccordionPanel>
618
+ <AccordionPanel>
619
+ The `frontendApi` argument passed to `authMiddleware` must be changed to `publishableKey`
620
+
621
+ ```diff
622
+ import { authMiddleware } from "@clerk/nextjs/server"
623
+
624
+ - authMiddleware({ frontendApi: '...' })
625
+ + authMiddleware({ publishableKey: '...' })
626
+ ```
627
+ </AccordionPanel>
628
+ <AccordionPanel>
629
+ The `apiKey` argument passed to `createClerkClient` must be changed to `secretKey`.
630
+
631
+ ```diff
632
+ import { createClerkClient } from '@clerk/nextjs/server';
633
+
634
+ - createClerkClient({ apiKey: '...' });
635
+ + createClerkClient({ secretKey: '...' });
636
+ ```
637
+ </AccordionPanel>
638
+ <AccordionPanel>
639
+ The `frontendApi` argument passed to `createClerkClient` must be changed to `publishableKey`. Note that the values of the two keys are different, so both keys and values need to be changed. You can find your application's publishable key in the Clerk dashboard.
640
+
641
+ ```diff
642
+ import { createClerkClient } from '@clerk/nextjs/server';
643
+
644
+ - createClerkClient({ frontendApi: '...' });
645
+ + createClerkClient({ publishableKey: '...' });
646
+ ```
647
+ </AccordionPanel>
648
+ <AccordionPanel>
649
+ The `apiKey` argument passed to `getAuth` must be changed to `secretKey`.
650
+
651
+ ```diff
652
+ - getAuth({ apiKey: '...' })
653
+ + getAuth({ secretKey: '...' })
654
+ ```
655
+ </AccordionPanel>
656
+ <AccordionPanel>
657
+ The `frontendApi` prop passed to `<ClerkProvider>` was renamed to `publishableKey`. **Note:** The values are different, so this is not just a key replacement. You can visit your [Clerk dashboard](https://dashboard.clerk.com/last-active?path=api-keys) to copy/paste the new keys after choosing your framework. Make sure to update this in all environments (e.g. dev, staging, production). [More information](/docs/deployments/overview#api-keys-and-environment-variables).
658
+ </AccordionPanel>
659
+ <AccordionPanel>
660
+ If you are using the `@clerk/nextjs/app-beta` import anywhere, it should use `@clerk/nextjs` instead. The `app-beta` import has been removed as our approuter support is stable, if there are any places you’re using it you can remove.
661
+
662
+ Make this change carefully as some behavior may have changed between our beta and stable releases. You can refer to [our documentation](https://clerk.com/docs/quickstarts/nextjs) and/or [approuter example](https://github.com/clerk/clerk-nextjs-app-quickstart) for up-to-date usage.
663
+
664
+ The `@clerk/nextjs` import will work with both App Router and Pages Router.
665
+ </AccordionPanel>
666
+ <AccordionPanel>
667
+ If you are importing from `@clerk/nextjs/ssr`, you can use `@clerk/nextjs` instead. Our top-level import supports SSR functionality by default now, so the subpath on the import is no longer needed. This import can be directly replaced without any other considerations.
668
+ </AccordionPanel>
669
+ <AccordionPanel>
670
+ This deprecated import has been replaced by `@clerk/nextjs`. Usage should now look as such: `import { authMiddleware } from @clerk/nextjs`. There may be changes in functionality between the two exports depending on how old the version used is, so upgrade with caution.
671
+ </AccordionPanel>
672
+ <AccordionPanel>
673
+ This deprecated import has been replaced by `@clerk/nextjs`. Usage should now look as such: `import { authMiddleware } from @clerk/nextjs`. There may be changes in functionality between the two exports depending on how old the version used is, so upgrade with caution.
674
+ </AccordionPanel>
675
+ <AccordionPanel>
676
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `CLERK_API_URL` environment variable.
677
+ </AccordionPanel>
678
+ <AccordionPanel>
679
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `CLERK_API_VERSION` environment variable.
680
+ </AccordionPanel>
681
+ <AccordionPanel>
682
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_JS` environment variable.
683
+ </AccordionPanel>
684
+ <AccordionPanel>
685
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_JS_VERSION` environment variable.
686
+ </AccordionPanel>
687
+ <AccordionPanel>
688
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_DOMAIN` environment variable.
689
+ </AccordionPanel>
690
+ <AccordionPanel>
691
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_IS_SATELLITE` environment variable.
692
+ </AccordionPanel>
693
+ <AccordionPanel>
694
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_PROXY_URL` environment variable.
695
+ </AccordionPanel>
696
+ <AccordionPanel>
697
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` environment variable.
698
+ </AccordionPanel>
699
+ <AccordionPanel>
700
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `CLERK_SECRET_KEY` environment variable.
701
+ </AccordionPanel>
702
+ <AccordionPanel>
703
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_SIGN_IN_URL` environment variable.
704
+ </AccordionPanel>
705
+ <AccordionPanel>
706
+ This deprecated constant has been removed as an export from `@clerk/nextjs`. Instead, set and use the `NEXT_PUBLIC_CLERK_SIGN_UP_URL` environment variable.
707
+ </AccordionPanel>
708
+ <AccordionPanel>
709
+ The import subpath `@clerk/nextjs/api` has been removed. This includes the following imports:
710
+
711
+ ```js
712
+ // These have been removed
713
+ import {
714
+ ClerkMiddleware,
715
+ ClerkMiddlewareOptions,
716
+ LooseAuthProp,
717
+ RequireAuthProp,
718
+ StrictAuthProp,
719
+ WithAuthProp,
720
+ } from '@clerk/nextjs/api';
721
+ ```
722
+
723
+ If you still need to use any of these functions, they can be instead imported from `@clerk/clerk-sdk-node`.
724
+ </AccordionPanel>
725
+ <AccordionPanel>
726
+ The `MultiSessionAppSupport` import path has changed from `@clerk/nextjs` to `@clerk/nextjs/internal`. You must update your import path in order for it to work correctly. Note that internal imports are not intended for usage and are outside the scope of semver. Example below of the fix that needs to be made:
727
+
728
+ ```diff
729
+ - import { MultiSessionAppSupport } from "@clerk/nextjs"
730
+ + import { MultiSessionAppSupport } from "@clerk/nextjs/internal"
731
+ ```
732
+ </AccordionPanel>
733
+ <AccordionPanel>
734
+ If you are using `NEXT_PUBLIC_CLERK_JS` as an environment variable, it should be changed to `NEXT_PUBLIC_CLERK_JS_URL` instead. This variable was renamed for consistency across public APIs. Make sure to also check your production host configuration when changing environment variable values.
735
+ </AccordionPanel>
736
+ </Accordion>
737
+
738
+ #### Other Breaking changes
739
+
740
+ <Accordion titles={["<code>Organization.getRoles</code> arguments changed", "<code>Organization.getMemberships</code> arguments changed", "<code>Organization.getDomains</code> arguments changed", "<code>Organization.getInvitations</code> arguments changed", "<code>Organization.getMembershipRequests</code> arguments changed", "<code>User.getOrganizationInvitations</code> arguments changed", "<code>User.getOrganizationSuggestions</code> arguments changed", "<code>User.getOrganizationMemberships</code> arguments changed", "<code>Users.getOrganizationMembershipList</code> return signature changed", "<code>Users.getOrganizationInvitationList</code> return signature changed", "<code>Organizations.getOrganizationInvitationList</code> return type changed", "<code>User.getOrganizationMembershipList</code> return type changed", "<code>Users.getOrganizationList</code> return signature changed", "<code>Organization.getOrganizationList</code> return type changed", "<code>Invitations.getInvitationList</code> return signature changed", "<code>Sessions.getSessionList</code> return signature changed", "<code>Users.getUserList</code> return signature changed", "<code>AllowlistIdentifiers.getAllowlistIdentifierList</code> return signature changed", "<code>Clients.getClientList</code> return signature changed", "<code>RedirectUrls.getRedirectUrlList</code> return signature changed", "<code>Users.getUserOauthAccessToken</code> return signature changed", "<code>setSession</code> -&gt; <code>setActive</code>", "<code>Organization.create(&#39;x&#39;)</code> -&gt; <code>Organization.create({ name: &#39;x&#39; })</code>", "<code>Organization.getPendingInvitations()</code> -&gt; <code>Organization.getInvitations({ status: &#39;pending&#39; })</code>", "<code>API_URL</code> value has changed", "<code>isMagicLinkError</code> -&gt; <code>isEmailLinkError</code>", "<code>useMagicLink</code> -&gt; <code>useEmailLink</code>", "<code>MagicLinkErrorCode</code> -&gt; <code>EmailLinkErrorCode</code>", "<code>isMetamaskError</code> import moved under <code>/errors</code>", "<code>WithSession</code> component removed", "<code>WithClerk</code> component removed", "<code>WithUser</code> component removed", "<code>withClerk</code> function removed", "<code>withSession</code> function removed", "<code>withUser</code> function removed", "Replace <code>signOutCallback</code> prop on <code>SignOutButton</code> with <code>redirectUrl</code>"]}>
741
+ <AccordionPanel>
742
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
743
+
744
+ ```diff
745
+ const { data } = await organization.getRoles({
746
+ - limit: 10,
747
+ + pageSize: 10,
748
+ - offset: 10,
749
+ + initialPage: 2,
750
+ })
751
+ ```
752
+ </AccordionPanel>
753
+ <AccordionPanel>
754
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
755
+
756
+ ```diff
757
+ const { data } = await organization.getMemberships({
758
+ - limit: 10,
759
+ + pageSize: 10,
760
+ - offset: 10,
761
+ + initialPage: 2,
762
+ })
763
+ ```
764
+ </AccordionPanel>
765
+ <AccordionPanel>
766
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
767
+
768
+ ```diff
769
+ const { data } = await organization.getDomains({
770
+ - limit: 10,
771
+ + pageSize: 10,
772
+ - offset: 10,
773
+ + initialPage: 2,
774
+ })
775
+ ```
776
+ </AccordionPanel>
777
+ <AccordionPanel>
778
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
779
+
780
+ ```diff
781
+ const { data } = await organization.getInvitations({
782
+ - limit: 10,
783
+ + pageSize: 10,
784
+ - offset: 10,
785
+ + initialPage: 2,
786
+ })
787
+ ```
788
+ </AccordionPanel>
789
+ <AccordionPanel>
790
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
791
+
792
+ ```diff
793
+ const { data } = await organization.getMembershipRequests({
794
+ - limit: 10,
795
+ + pageSize: 10,
796
+ - offset: 10,
797
+ + initialPage: 2,
798
+ })
799
+ ```
800
+ </AccordionPanel>
801
+ <AccordionPanel>
802
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
803
+
804
+ ```diff
805
+ const { data } = await user.getOrganizationInvitations({
806
+ - limit: 10,
807
+ + pageSize: 10,
808
+ - offset: 10,
809
+ + initialPage: 2,
810
+ })
811
+ ```
812
+ </AccordionPanel>
813
+ <AccordionPanel>
814
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
815
+
816
+ ```diff
817
+ const { data } = await user.getOrganizationSuggestions({
818
+ - limit: 10,
819
+ + pageSize: 10,
820
+ - offset: 10,
821
+ + initialPage: 2,
822
+ })
823
+ ```
824
+ </AccordionPanel>
825
+ <AccordionPanel>
826
+ There have been a couple changes to the pagination arguments that can be passed into this function - `limit` has been renamed to `pageSize`, and `offset` has been renamed to `initialPage`. This will help to make it more clear and simple to reason about pagination control. Example of how changes might look below:
827
+
828
+ ```diff
829
+ const { data } = await user.getOrganizationMemberships({
830
+ - limit: 10,
831
+ + pageSize: 10,
832
+ - offset: 10,
833
+ + initialPage: 2,
834
+ })
835
+ ```
836
+ </AccordionPanel>
837
+ <AccordionPanel>
838
+ The response payload of `Users.getOrganizationMembershipList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
839
+
840
+ Here's an example of how the response shape would change with this modification:
841
+
842
+ ```diff
843
+ - const data = await clerkClient.users.getOrganizationMembershipList()
844
+ + const { data, totalCount } = await clerkClient.users.getOrganizationMembershipList()
845
+ ```
846
+ </AccordionPanel>
847
+ <AccordionPanel>
848
+ The response payload of `Users.getOrganizationInvitationList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
849
+
850
+ Here's an example of how the response shape would change with this modification:
851
+
852
+ ```diff
853
+ - const data = await clerkClient.users.getOrganizationInvitationList()
854
+ + const { data, totalCount } = await clerkClient.users.getOrganizationInvitationList()
855
+ ```
856
+ </AccordionPanel>
857
+ <AccordionPanel>
858
+ The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since Clerk's API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily. A before/after code example can be seen below:
859
+
860
+ ```diff
861
+ const data = await clerkClient.organizations.getOrganizationInvitationList({
862
+ organizationId: "...",
863
+ })
864
+
865
+ - data.forEach(() => {})
866
+ + data.data.forEach(() => {})
867
+ ```
868
+ </AccordionPanel>
869
+ <AccordionPanel>
870
+ The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since Clerk's API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily. A before/after code example can be seen below:
871
+
872
+ ```diff
873
+ const { user } = useUser()
874
+ const membershipList = user.getOrganizationMembershipList()
875
+
876
+ - membershipList.forEach(() => {})
877
+ + membershipList.data.forEach(() => {})
878
+ ```
879
+ </AccordionPanel>
880
+ <AccordionPanel>
881
+ The response payload of `Users.getOrganizationList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
882
+
883
+ Here's an example of how the response shape would change with this modification:
884
+
885
+ ```diff
886
+ - const data = await clerkClient.users.getOrganizationList()
887
+ + const { data, totalCount } = await clerkClient.users.getOrganizationList()
888
+ ```
889
+ </AccordionPanel>
890
+ <AccordionPanel>
891
+ The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since Clerk's API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily. A before/after code example can be seen below:
892
+
893
+ ```diff
894
+ const { organization } = useOrganization()
895
+ const orgList = organization.getOrganizationList()
896
+
897
+ - orgList.forEach(() => {})
898
+ + orgList.data.forEach(() => {})
899
+ ```
900
+ </AccordionPanel>
901
+ <AccordionPanel>
902
+ The response payload of `Invitations.getInvitationList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
903
+
904
+ Here's an example of how the response shape would change with this modification:
905
+
906
+ ```diff
907
+ - const data = await clerkClient.invitations.getInvitationList()
908
+ + const { data, totalCount } = await clerkClient.invitations.getInvitationList()
909
+ ```
910
+ </AccordionPanel>
911
+ <AccordionPanel>
912
+ The response payload of `Sessions.getSessionList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
913
+
914
+ Here's an example of how the response shape would change with this modification:
915
+
916
+ ```diff
917
+ - const data = await clerkClient.sessions.getSessionList()
918
+ + const { data, totalCount } = await clerkClient.sessions.getSessionList()
919
+ ```
920
+ </AccordionPanel>
921
+ <AccordionPanel>
922
+ The response payload of `Users.getUserList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
923
+
924
+ Here's an example of how the response shape would change with this modification:
925
+
926
+ ```diff
927
+ - const data = await clerkClient.users.getUserList()
928
+ + const { data, totalCount } = await clerkClient.users.getUserList()
929
+ ```
930
+ </AccordionPanel>
931
+ <AccordionPanel>
932
+ The response payload of `AllowlistIdentifiers.getAllowlistIdentifierList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
933
+
934
+ Here's an example of how the response shape would change with this modification:
935
+
936
+ ```diff
937
+ - const data = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
938
+ + const { data, totalCount } = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
939
+ ```
940
+ </AccordionPanel>
941
+ <AccordionPanel>
942
+ The response payload of `Clients.getClientList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
943
+
944
+ Here's an example of how the response shape would change with this modification:
945
+
946
+ ```diff
947
+ - const data = await clerkClient.clients.getClientList()
948
+ + const { data, totalCount } = await clerkClient.allowlistIdentifiers.getClientList()
949
+ ```
950
+ </AccordionPanel>
951
+ <AccordionPanel>
952
+ The response payload of `RedirectUrls.getRedirectUrlList` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
953
+
954
+ Here's an example of how the response shape would change with this modification:
955
+
956
+ ```diff
957
+ - const data = await clerkClient.redirectUrls.getRedirectUrlList()
958
+ + const { data, totalCount } = await clerkClient.redirectUrls.getRedirectUrlList()
959
+ ```
960
+ </AccordionPanel>
961
+ <AccordionPanel>
962
+ The response payload of `Users.getUserOauthAccessToken` was changed as part of the core 2 release. Rather than directly returning ` data`, the return signature is now `{ data, totalCount }`. Since backend API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily, and this change in the backend SDK aligns the response shape with what the backend API returns directly.
963
+
964
+ Here's an example of how the response shape would change with this modification:
965
+
966
+ ```diff
967
+ - const data = await clerkClient.users.getUserOauthAccessToken()
968
+ + const { data, totalCount } = await clerkClient.users.getUserOauthAccessToken()
969
+ ```
970
+ </AccordionPanel>
971
+ <AccordionPanel>
972
+ `setSession` should be replaced with `setActive`. The format of the parameters has changed slightly - `setActive` takes an object where `setSession` took params directly. The `setActive` function also can accept an `organization` param that is used to set the currently active organization. The return signature did not change. Read the [API documentation](/docs/references/javascript/clerk/session-methods#set-active) for more detail. This function should be expected to be returned from one of the following Clerk hooks: `useSessionList`, `useSignUp`, or `useSignIn`. Some migration examples:
973
+
974
+ ```diff
975
+ - await setSession('sessionID', () => void)
976
+ + await setActive({ session: 'sessionID', beforeEmit: () => void })
977
+
978
+ - await setSession(sessionObj)
979
+ + await setActive({ session: sessionObj })
980
+
981
+ - await setSession(sessionObj, () => void)
982
+ + await setActive({ session: sessionObj, beforeEmit: () => void })
983
+ ```
984
+
985
+ `setActive` also supports setting an active organization:
986
+
987
+ ```js
988
+ await setActive({
989
+ session: 'sessionID',
990
+ organization: 'orgID',
991
+ beforeEmit: () => void
992
+ })
993
+
994
+ await setActive({
995
+ session: sessionObj,
996
+ organization: orgObj,
997
+ beforeEmit: () => void
998
+ })
999
+ ```
1000
+ </AccordionPanel>
1001
+ <AccordionPanel>
1002
+ Passing a string as an argument to `Organization.create` is no longer possible - instead, pass an object with the `name` property.
1003
+
1004
+ ```diff
1005
+ - Organization.create('...');
1006
+ + Organization.create({ name: '...' });
1007
+ ```
1008
+ </AccordionPanel>
1009
+ <AccordionPanel>
1010
+ The `Organization.getPendingInvitations()` method has been removed. You can use `Organization.getInvitations` instead.
1011
+
1012
+ ```diff
1013
+ - Organization.getPendingInvitations();
1014
+ + Organization.getInvitations({ status: 'pending' });
1015
+ ```
1016
+ </AccordionPanel>
1017
+ <AccordionPanel>
1018
+ The value of this export has changed from `https://api.clerk.dev` to `https://api.clerk.com`. If you were relying on the text content of this value not changing, you may need to make adjustments.
1019
+ </AccordionPanel>
1020
+ <AccordionPanel>
1021
+ Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects the functionality.
1022
+ </AccordionPanel>
1023
+ <AccordionPanel>
1024
+ Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects functionality.
1025
+ </AccordionPanel>
1026
+ <AccordionPanel>
1027
+ Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects the functionality.
1028
+ </AccordionPanel>
1029
+ <AccordionPanel>
1030
+ The `isMetamaskError` import path has changed from `@clerk/react` to `@clerk/react/errors`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made:
1031
+
1032
+ ```diff
1033
+ - import { isMetamaskError } from "@clerk/react"
1034
+ + import { isMetamaskError } from "@clerk/react/errors"
1035
+ ```
1036
+ </AccordionPanel>
1037
+ <AccordionPanel>
1038
+ The `WithSession` higher order component has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1039
+
1040
+ ```js
1041
+ export const WithSession = ({ children }) => {
1042
+ const session = useSession();
1043
+ if (typeof children !== 'function') throw new Error();
1044
+
1045
+ return {children(session)};
1046
+ };
1047
+ ```
1048
+ </AccordionPanel>
1049
+ <AccordionPanel>
1050
+ The `WithClerk` higher order component has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1051
+
1052
+ ```js
1053
+ export const WithClerk = ({ children }) => {
1054
+ const clerk = useClerk();
1055
+ if (typeof children !== 'function') throw new Error();
1056
+
1057
+ return {children(clerk)};
1058
+ };
1059
+ ```
1060
+ </AccordionPanel>
1061
+ <AccordionPanel>
1062
+ The `WithUser` higher order component has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1063
+
1064
+ ```js
1065
+ export const WithUser = ({ children }) => {
1066
+ const user = useUser();
1067
+ if (typeof children !== 'function') throw new Error();
1068
+
1069
+ return {children(user)};
1070
+ };
1071
+ ```
1072
+ </AccordionPanel>
1073
+ <AccordionPanel>
1074
+ The `withClerk` higher order function has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1075
+
1076
+ ```js
1077
+ function withClerk(Component, displayName) {
1078
+ displayName = displayName || Component.displayName || Component.name || 'Component';
1079
+ Component.displayName = displayName;
1080
+ const HOC = props => {
1081
+ const clerk = useIsomorphicClerkContext();
1082
+
1083
+ if (!clerk.loaded) return null;
1084
+
1085
+ return (
1086
+ <Component
1087
+ {...props}
1088
+ clerk={clerk}
1089
+ />
1090
+ );
1091
+ };
1092
+
1093
+ HOC.displayName = `withClerk(${displayName})`;
1094
+ return HOC;
1095
+ }
1096
+ ```
1097
+ </AccordionPanel>
1098
+ <AccordionPanel>
1099
+ The `withSession` higher order function has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1100
+
1101
+ ```js
1102
+ function withSession(Component, displayName) {
1103
+ displayName = displayName || Component.displayName || Component.name || 'Component';
1104
+ Component.displayName = displayName;
1105
+ const HOC = props => {
1106
+ const session = useSessionContext();
1107
+
1108
+ if (!session) return null;
1109
+
1110
+ return (
1111
+ <Component
1112
+ {...props}
1113
+ session={session}
1114
+ />
1115
+ );
1116
+ };
1117
+
1118
+ HOC.displayName = `withSession(${displayName})`;
1119
+ return HOC;
1120
+ }
1121
+ ```
1122
+ </AccordionPanel>
1123
+ <AccordionPanel>
1124
+ The `withUser` higher order function has been removed. If you would still like to use this function in the way its implemented, it can be created quickly using Clerk's [custom hooks](https://clerk.com/docs/references/react/overview). An example of how to do so is below:
1125
+
1126
+ ```js
1127
+ function withUser(Component, displayName) {
1128
+ displayName = displayName || Component.displayName || Component.name || 'Component';
1129
+ Component.displayName = displayName;
1130
+ const HOC = props => {
1131
+ const clerk = useUserContext();
1132
+
1133
+ if (!user) return null;
1134
+
1135
+ return (
1136
+ <Component
1137
+ {...props}
1138
+ user={user}
1139
+ />
1140
+ );
1141
+ };
1142
+
1143
+ HOC.displayName = `withUser(${displayName})`;
1144
+ return HOC;
1145
+ }
1146
+ ```
1147
+ </AccordionPanel>
1148
+ <AccordionPanel>
1149
+ The `signOutCallback` prop on the [`<SignOutButton />` component](https://clerk.com/docs/components/unstyled/sign-out-button) has been removed. Instead, you can use the `redirectUrl` prop. Example below:
1150
+
1151
+ ```diff
1152
+ import { SignOutButton } from "@clerk/clerk-react";
1153
+
1154
+ export const Signout = () => {
1155
+ return (
1156
+ <SignOutButton
1157
+ - signOutCallback={() => { window.location.href = "/your-path" }}
1158
+ + redirectUrl="/your-path"
1159
+ >
1160
+ <button>Sign Out</button>
1161
+ </SignOutButton>
1162
+ )
1163
+ }
1164
+ ```
1165
+ </AccordionPanel>
1166
+ </Accordion>
1167
+
1168
+
1169
+