@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,530 @@
1
+ ---
2
+ title: "Upgrading Chrome Extension SDK to Core 2"
3
+ description: "Learn how to upgrade Clerk's Chrome Extension 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/chrome-extension` to Core 2
9
+
10
+ Core 2 is included in the Chrome Extension SDK starting with version 1. This new version ships with an improved design and UX for its built-in components, no "flash of white page" when authenticating, 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 project to use `@clerk/chrome-extension` v1. 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/chrome-extension@0`). Some changes required for Core 2 SDKs can be applied incrementally to the v1 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 to Core 2
46
+
47
+ 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.
48
+
49
+ <CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
50
+ ```bash filename="terminal"
51
+ npm install @clerk/chrome-extension
52
+ ```
53
+
54
+ ```bash filename="terminal"
55
+ yarn add @clerk/chrome-extension
56
+ ```
57
+
58
+ ```bash filename="terminal"
59
+ pnpm add @clerk/chrome-extension
60
+ ```
61
+
62
+ </CodeBlockTabs>
63
+
64
+ ## CLI upgrade helper
65
+
66
+ 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.
67
+
68
+ To run the CLI tool, navigate to your project and run it in the terminal:
69
+
70
+ <CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
71
+ ```bash filename="terminal"
72
+ npx @clerk/upgrade
73
+ ```
74
+
75
+ ```bash filename="terminal"
76
+ yarn dlx @clerk/upgrade
77
+ ```
78
+
79
+ ```bash filename="terminal"
80
+ pnpm dlx @clerk/upgrade
81
+ ```
82
+
83
+ </CodeBlockTabs>
84
+
85
+ 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.
86
+
87
+ ## Breaking Changes
88
+
89
+ ### `tokenCache` -> `storageCache` as `<ClerkProvider>` props
90
+
91
+ The `tokenCache` prop has been renamed to `storageCache` in order to accomodate the new [WebSSO feature](https://github.com/clerk/javascript/pull/2277). With the prop change from `tokenCache` to `storageCache`, the interface has been expanded to allow for more flexibility. The new interface is as follows:
92
+
93
+ ```ts
94
+ type StorageCache = {
95
+ createKey: (...keys: string[]) => string;
96
+ get: <T = any>(key: string) => Promise<T>;
97
+ remove: (key: string) => Promise<void>;
98
+ set: (key: string, value: string) => Promise<void>;
99
+ };
100
+ ```
101
+
102
+ And here's a full before/after example:
103
+
104
+ ```diff
105
+ - <ClerkProvider tokenCache={/* ... */}>
106
+ + <ClerkProvider storageCache={/* ... */}>
107
+ ```
108
+
109
+ ### Component design adjustments
110
+
111
+ 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.
112
+
113
+ [More detail on these changes &raquo;](component-redesign)
114
+
115
+ ### After sign up/in/out default value change
116
+
117
+ 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.
118
+
119
+ 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.
120
+
121
+ ```diff
122
+ - <UserButton afterSignOutUrl='/' />
123
+ + <UserButton />
124
+ ```
125
+
126
+ ### Removed: `orgs` claim on JWT
127
+
128
+ 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.
129
+
130
+ The `orgs` claim was part of the `JwtPayload`. Here are a few examples of where the `JwtPayload` could be found.
131
+
132
+ <Accordion titles={["Next.js", "Fastify", "@clerk/backend", "@clerk/clerk-sdk-node"]} heading="h5">
133
+ <AccordionPanel>
134
+ ```typescript filename="Next.js"
135
+ import { getAuth } from "@clerk/nextjs/server"
136
+ const claims: JwtPayload = getAuth(request).sessionClaims
137
+
138
+ import { getAuth } from "@clerk/ssr.server"
139
+ const claims: JwtPayload = (await getAuth(request)).sessionClaims
140
+ ```
141
+
142
+ </AccordionPanel>
143
+ <AccordionPanel>
144
+ ```typescript filename="Fastify"
145
+ import { getAuth } from "@clerk/fastify"
146
+ const claims: JwtPayload = (await getAuth(request)).sessionClaims
147
+ ```
148
+ </AccordionPanel>
149
+ <AccordionPanel>
150
+ ```typescript filename="@clerk/backend"
151
+ import { createClerkClient } from "@clerk/backend"
152
+
153
+ const clerkClient = createClerkClient({ secretKey: "" })
154
+ const requestState = await clerkClient.authenticateRequest(
155
+ request,
156
+ { publishableKey: "" }
157
+ )
158
+ const claims: JwtPayload = requestState.toAuth().sessionClaims
159
+ ```
160
+
161
+ </AccordionPanel>
162
+ <AccordionPanel>
163
+ ```typescript filename="@clerk/clerk-sdk-node"
164
+ import { clerkClient } from "@clerk/clerk-sdk-node"
165
+
166
+ router.use((...args) => clerkClient.expressRequireAuth()(...args))
167
+ router.get("/me", async (req, reply: Response) => {
168
+ return reply.json({ auth: req.auth })
169
+ })
170
+ ```
171
+
172
+ </AccordionPanel>
173
+ </Accordion>
174
+
175
+ 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.
176
+
177
+ ### Path routing is now the default
178
+
179
+ 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.
180
+
181
+ 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:
182
+
183
+ - `<SignIn />`
184
+ - `<SignUp />`
185
+ - `<UserProfile />`
186
+ - `<CreateOrganization />`
187
+ - `<OrganizationProfile />`
188
+
189
+ Here's how you'd use the components going forward:
190
+
191
+ ```jsx
192
+ <SignIn path="/sign-in" />
193
+ <SignUp path="/sign-up" />
194
+ <UserProfile path="/user-profile" />
195
+ <CreateOrganization path="/create-org" />
196
+ <OrganizationProfile path="/org-profile" />
197
+ ```
198
+
199
+ If you don't define the `path` prop an error will be thrown. Of course, you can still use `routing="hash"` or `routing="virtual"`.
200
+
201
+ ```jsx
202
+ <UserProfile routing="hash" />
203
+ <OrganizationProfile routing="virtual" />
204
+ ```
205
+
206
+
207
+
208
+ ### Image URL Name Consolidation
209
+
210
+ 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:
211
+
212
+ <Accordion titles={["<code>Organization.logoUrl</code> -&gt; <code>Organization.imageUrl</code>", "<code>User.profileImageUrl</code> -&gt; <code>.imageUrl</code>"]}>
213
+ <AccordionPanel>
214
+ The `logoUrl` property of any [`Organization` object](https://clerk.com/docs/references/javascript/organization/organization#organization) has been changed to `imageUrl`.
215
+ </AccordionPanel>
216
+ <AccordionPanel>
217
+ The `profileImageUrl` property of any `User` object has been changed to `imageUrl`.
218
+ </AccordionPanel>
219
+ </Accordion>
220
+
221
+ ### Deprecation removals & housekeeping
222
+
223
+ 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.
224
+
225
+ <Callout type='info'>
226
+ For this section more than any other one, please use the CLI upgrade tool (`npx @clerk/upgrade`). Changes in this
227
+ section are very unlikely to appear in your codebase, the tool will save time looking for them.
228
+ </Callout>
229
+
230
+ #### Deprecation removals
231
+
232
+ <Accordion titles={["<code>User.update({ password: &#39;x&#39; })</code> -&gt; <code>User.updatePassword(&#39;x&#39;)</code>"]}>
233
+ <AccordionPanel>
234
+ 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:
235
+
236
+ ```diff
237
+ - user.update({ password: 'foo' });
238
+
239
+ + user.updatePassword({
240
+ + currentPassword: 'bar',
241
+ + newPassword: 'foo',
242
+ + signOutOfOtherSessions: true,
243
+ + });
244
+ ```
245
+ </AccordionPanel>
246
+ </Accordion>
247
+
248
+ #### Other Breaking changes
249
+
250
+ <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>"]}>
251
+ <AccordionPanel>
252
+ 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:
253
+
254
+ ```diff
255
+ const { data } = await organization.getRoles({
256
+ - limit: 10,
257
+ + pageSize: 10,
258
+ - offset: 10,
259
+ + initialPage: 2,
260
+ })
261
+ ```
262
+ </AccordionPanel>
263
+ <AccordionPanel>
264
+ 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:
265
+
266
+ ```diff
267
+ const { data } = await organization.getMemberships({
268
+ - limit: 10,
269
+ + pageSize: 10,
270
+ - offset: 10,
271
+ + initialPage: 2,
272
+ })
273
+ ```
274
+ </AccordionPanel>
275
+ <AccordionPanel>
276
+ 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:
277
+
278
+ ```diff
279
+ const { data } = await organization.getDomains({
280
+ - limit: 10,
281
+ + pageSize: 10,
282
+ - offset: 10,
283
+ + initialPage: 2,
284
+ })
285
+ ```
286
+ </AccordionPanel>
287
+ <AccordionPanel>
288
+ 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:
289
+
290
+ ```diff
291
+ const { data } = await organization.getInvitations({
292
+ - limit: 10,
293
+ + pageSize: 10,
294
+ - offset: 10,
295
+ + initialPage: 2,
296
+ })
297
+ ```
298
+ </AccordionPanel>
299
+ <AccordionPanel>
300
+ 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:
301
+
302
+ ```diff
303
+ const { data } = await organization.getMembershipRequests({
304
+ - limit: 10,
305
+ + pageSize: 10,
306
+ - offset: 10,
307
+ + initialPage: 2,
308
+ })
309
+ ```
310
+ </AccordionPanel>
311
+ <AccordionPanel>
312
+ 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:
313
+
314
+ ```diff
315
+ const { data } = await user.getOrganizationInvitations({
316
+ - limit: 10,
317
+ + pageSize: 10,
318
+ - offset: 10,
319
+ + initialPage: 2,
320
+ })
321
+ ```
322
+ </AccordionPanel>
323
+ <AccordionPanel>
324
+ 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:
325
+
326
+ ```diff
327
+ const { data } = await user.getOrganizationSuggestions({
328
+ - limit: 10,
329
+ + pageSize: 10,
330
+ - offset: 10,
331
+ + initialPage: 2,
332
+ })
333
+ ```
334
+ </AccordionPanel>
335
+ <AccordionPanel>
336
+ 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:
337
+
338
+ ```diff
339
+ const { data } = await user.getOrganizationMemberships({
340
+ - limit: 10,
341
+ + pageSize: 10,
342
+ - offset: 10,
343
+ + initialPage: 2,
344
+ })
345
+ ```
346
+ </AccordionPanel>
347
+ <AccordionPanel>
348
+ 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.
349
+
350
+ Here's an example of how the response shape would change with this modification:
351
+
352
+ ```diff
353
+ - const data = await clerkClient.users.getOrganizationMembershipList()
354
+ + const { data, totalCount } = await clerkClient.users.getOrganizationMembershipList()
355
+ ```
356
+ </AccordionPanel>
357
+ <AccordionPanel>
358
+ 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.
359
+
360
+ Here's an example of how the response shape would change with this modification:
361
+
362
+ ```diff
363
+ - const data = await clerkClient.users.getOrganizationInvitationList()
364
+ + const { data, totalCount } = await clerkClient.users.getOrganizationInvitationList()
365
+ ```
366
+ </AccordionPanel>
367
+ <AccordionPanel>
368
+ 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:
369
+
370
+ ```diff
371
+ const data = await clerkClient.organizations.getOrganizationInvitationList({
372
+ organizationId: "...",
373
+ })
374
+
375
+ - data.forEach(() => {})
376
+ + data.data.forEach(() => {})
377
+ ```
378
+ </AccordionPanel>
379
+ <AccordionPanel>
380
+ 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:
381
+
382
+ ```diff
383
+ const { user } = useUser()
384
+ const membershipList = user.getOrganizationMembershipList()
385
+
386
+ - membershipList.forEach(() => {})
387
+ + membershipList.data.forEach(() => {})
388
+ ```
389
+ </AccordionPanel>
390
+ <AccordionPanel>
391
+ 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.
392
+
393
+ Here's an example of how the response shape would change with this modification:
394
+
395
+ ```diff
396
+ - const data = await clerkClient.users.getOrganizationList()
397
+ + const { data, totalCount } = await clerkClient.users.getOrganizationList()
398
+ ```
399
+ </AccordionPanel>
400
+ <AccordionPanel>
401
+ 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:
402
+
403
+ ```diff
404
+ const { organization } = useOrganization()
405
+ const orgList = organization.getOrganizationList()
406
+
407
+ - orgList.forEach(() => {})
408
+ + orgList.data.forEach(() => {})
409
+ ```
410
+ </AccordionPanel>
411
+ <AccordionPanel>
412
+ 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.
413
+
414
+ Here's an example of how the response shape would change with this modification:
415
+
416
+ ```diff
417
+ - const data = await clerkClient.invitations.getInvitationList()
418
+ + const { data, totalCount } = await clerkClient.invitations.getInvitationList()
419
+ ```
420
+ </AccordionPanel>
421
+ <AccordionPanel>
422
+ 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.
423
+
424
+ Here's an example of how the response shape would change with this modification:
425
+
426
+ ```diff
427
+ - const data = await clerkClient.sessions.getSessionList()
428
+ + const { data, totalCount } = await clerkClient.sessions.getSessionList()
429
+ ```
430
+ </AccordionPanel>
431
+ <AccordionPanel>
432
+ 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.
433
+
434
+ Here's an example of how the response shape would change with this modification:
435
+
436
+ ```diff
437
+ - const data = await clerkClient.users.getUserList()
438
+ + const { data, totalCount } = await clerkClient.users.getUserList()
439
+ ```
440
+ </AccordionPanel>
441
+ <AccordionPanel>
442
+ 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.
443
+
444
+ Here's an example of how the response shape would change with this modification:
445
+
446
+ ```diff
447
+ - const data = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
448
+ + const { data, totalCount } = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
449
+ ```
450
+ </AccordionPanel>
451
+ <AccordionPanel>
452
+ 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.
453
+
454
+ Here's an example of how the response shape would change with this modification:
455
+
456
+ ```diff
457
+ - const data = await clerkClient.clients.getClientList()
458
+ + const { data, totalCount } = await clerkClient.allowlistIdentifiers.getClientList()
459
+ ```
460
+ </AccordionPanel>
461
+ <AccordionPanel>
462
+ 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.
463
+
464
+ Here's an example of how the response shape would change with this modification:
465
+
466
+ ```diff
467
+ - const data = await clerkClient.redirectUrls.getRedirectUrlList()
468
+ + const { data, totalCount } = await clerkClient.redirectUrls.getRedirectUrlList()
469
+ ```
470
+ </AccordionPanel>
471
+ <AccordionPanel>
472
+ 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.
473
+
474
+ Here's an example of how the response shape would change with this modification:
475
+
476
+ ```diff
477
+ - const data = await clerkClient.users.getUserOauthAccessToken()
478
+ + const { data, totalCount } = await clerkClient.users.getUserOauthAccessToken()
479
+ ```
480
+ </AccordionPanel>
481
+ <AccordionPanel>
482
+ `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:
483
+
484
+ ```diff
485
+ - await setSession('sessionID', () => void)
486
+ + await setActive({ session: 'sessionID', beforeEmit: () => void })
487
+
488
+ - await setSession(sessionObj)
489
+ + await setActive({ session: sessionObj })
490
+
491
+ - await setSession(sessionObj, () => void)
492
+ + await setActive({ session: sessionObj, beforeEmit: () => void })
493
+ ```
494
+
495
+ `setActive` also supports setting an active organization:
496
+
497
+ ```js
498
+ await setActive({
499
+ session: 'sessionID',
500
+ organization: 'orgID',
501
+ beforeEmit: () => void
502
+ })
503
+
504
+ await setActive({
505
+ session: sessionObj,
506
+ organization: orgObj,
507
+ beforeEmit: () => void
508
+ })
509
+ ```
510
+ </AccordionPanel>
511
+ <AccordionPanel>
512
+ Passing a string as an argument to `Organization.create` is no longer possible - instead, pass an object with the `name` property.
513
+
514
+ ```diff
515
+ - Organization.create('...');
516
+ + Organization.create({ name: '...' });
517
+ ```
518
+ </AccordionPanel>
519
+ <AccordionPanel>
520
+ The `Organization.getPendingInvitations()` method has been removed. You can use `Organization.getInvitations` instead.
521
+
522
+ ```diff
523
+ - Organization.getPendingInvitations();
524
+ + Organization.getInvitations({ status: 'pending' });
525
+ ```
526
+ </AccordionPanel>
527
+ </Accordion>
528
+
529
+
530
+