@clerk/upgrade 1.0.1 → 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.
- package/dist/guide-generators/core-2/backend/__output.mdx +687 -0
- package/dist/guide-generators/core-2/chrome-extension/__output.mdx +530 -0
- package/dist/guide-generators/core-2/expo/__output.mdx +546 -0
- package/dist/guide-generators/core-2/fastify/__output.mdx +448 -0
- package/dist/guide-generators/core-2/gatsby/__output.mdx +503 -0
- package/dist/guide-generators/core-2/js/__output.mdx +628 -0
- package/dist/guide-generators/core-2/nextjs/__output.mdx +1169 -0
- package/dist/guide-generators/core-2/node/__output.mdx +592 -0
- package/dist/guide-generators/core-2/overview/__output.mdx +33 -0
- package/dist/guide-generators/core-2/overview/intro.mdx +1 -1
- package/dist/guide-generators/core-2/react/__output.mdx +790 -0
- package/dist/guide-generators/core-2/remix/__output.mdx +432 -0
- package/dist/guide-generators/core-2/retheme/__output.mdx +440 -0
- package/dist/guide-generators/core-2/shared/prepare.mdx +0 -5
- package/dist/guide-generators/core-2/shared/update-version.mdx +5 -5
- package/dist/versions/core-2/backend/members-count.md +2 -2
- package/dist/versions/core-2/index.js +1 -1
- package/dist/versions/core-2/nextjs/auth-middleware-deprecated.md +2 -2
- package/dist/versions/core-2/nextjs/authmiddleware-import-change.md +1 -1
- package/dist/versions/core-2/nextjs/with-clerk-middleware-removed.md +1 -1
- package/dist/versions/core-2/node/createclerkexpressrequireauth-public-key-required.md +2 -2
- package/dist/versions/core-2/node/createclerkexpresswithauth-publickey-required.md +7 -0
- package/package.json +1 -1
- /package/dist/versions/core-2/{js/supported-external-accounts-type-removed.md → common/supported-external-accounts-removed.md} +0 -0
|
@@ -0,0 +1,687 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Upgrading Backend to Core 2"
|
|
3
|
+
description: "Learn how to upgrade Clerk's Backend 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/backend` to Core 2
|
|
9
|
+
|
|
10
|
+
Core 2 is included in the Backend SDK starting with version 1. This new version ships with 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 Backend project to use `@clerk/backend` 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/backend@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 to Core 2
|
|
25
|
+
|
|
26
|
+
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.
|
|
27
|
+
|
|
28
|
+
<CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
|
|
29
|
+
```bash filename="terminal"
|
|
30
|
+
npm install @clerk/backend
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
```bash filename="terminal"
|
|
34
|
+
yarn add @clerk/backend
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
```bash filename="terminal"
|
|
38
|
+
pnpm add @clerk/backend
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
</CodeBlockTabs>
|
|
42
|
+
|
|
43
|
+
## CLI upgrade helper
|
|
44
|
+
|
|
45
|
+
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.
|
|
46
|
+
|
|
47
|
+
To run the CLI tool, navigate to your project and run it in the terminal:
|
|
48
|
+
|
|
49
|
+
<CodeBlockTabs type="installer" options={["npm", "yarn", "pnpm"]}>
|
|
50
|
+
```bash filename="terminal"
|
|
51
|
+
npx @clerk/upgrade
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
```bash filename="terminal"
|
|
55
|
+
yarn dlx @clerk/upgrade
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
```bash filename="terminal"
|
|
59
|
+
pnpm dlx @clerk/upgrade
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
</CodeBlockTabs>
|
|
63
|
+
|
|
64
|
+
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.
|
|
65
|
+
|
|
66
|
+
## Breaking Changes
|
|
67
|
+
|
|
68
|
+
### `request` separated from `options` as params to `authenticateRequest`
|
|
69
|
+
|
|
70
|
+
There has been a change to the way the params of the `authenticateRequest` function are structured. The `request` param, formerly included in an `options` object, has been moved to stand on its own as the first param to the function, while the `options` object remains as the second param. Example below:
|
|
71
|
+
|
|
72
|
+
```diff
|
|
73
|
+
- clerkClient.authenticateRequest({ ...opts, request })
|
|
74
|
+
+ clerkClient.authenticateRequest(request, { ...opts })
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### `clockSkewInSeconds` -> `clockSkewInMs`
|
|
78
|
+
|
|
79
|
+
The `clockSkewInSeconds` option has been renamed to `clockSkewInMs` in order to accurately reflect that its value is expected to be in milliseconds rather than seconds. The value does not need to change here, only the name. This change affects the following imports:
|
|
80
|
+
|
|
81
|
+
- `verifyJwt`
|
|
82
|
+
- `verifyToken`
|
|
83
|
+
- `Clerk.authenticateRequest`
|
|
84
|
+
|
|
85
|
+
### Import paths changes
|
|
86
|
+
|
|
87
|
+
Some top level import paths have been changed in order to improve tree-shaking and more clearly categorize sets of functionality. Some methods have been moved under an `/internal` path, indicating that they are only intended for internal use, are exempt from semver, and should be used with great caution.
|
|
88
|
+
|
|
89
|
+
<Accordion titles={["<code>verifyJwt</code> import moved to <code>@clerk/backend/tokens</code>", "<code>decodeJwt</code> import moved to <code>@clerk/backend/tokens</code>", "<code>signJwt</code> import moved to <code>@clerk/backend/tokens</code>", "<code>constants</code> import moved to <code>@clerk/backend/internal</code>", "<code>redirect</code> import moved to <code>@clerk/backend/internal</code>", "<code>createAuthenticateRequest</code> import moved to <code>@clerk/backend/internal</code>", "<code>createIsomorphicRequest</code> import moved to <code>@clerk/backend/internal</code>", "<code>createIsomorphicRequest</code> import moved to <code>/internal</code>", "<code>SignJWTError</code> import moved to <code>@clerk/backend/errors</code>", "<code>TokenVerificationError</code> import moved to <code>@clerk/backend/errors</code>", "<code>TokenVerificationErrorAction</code> import moved to <code>@clerk/backend/errors</code>", "<code>TokenVerificationErrorReason</code> import moved to <code>@clerk/backend/errors</code>"]}>
|
|
90
|
+
<AccordionPanel>
|
|
91
|
+
The `verifyJwt` import path has changed from `@clerk/backend` to `@clerk/backend/tokens`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made
|
|
92
|
+
|
|
93
|
+
```diff
|
|
94
|
+
- import { verifyJwt } from "@clerk/backend"
|
|
95
|
+
+ import { verifyJwt } from "@clerk/backend/tokens"
|
|
96
|
+
```
|
|
97
|
+
</AccordionPanel>
|
|
98
|
+
<AccordionPanel>
|
|
99
|
+
The `decodeJwt` import path has changed from `@clerk/backend` to `@clerk/backend/tokens`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made
|
|
100
|
+
|
|
101
|
+
```diff
|
|
102
|
+
- import { decodeJwt } from "@clerk/backend"
|
|
103
|
+
+ import { decodeJwt } from "@clerk/backend/tokens"
|
|
104
|
+
```
|
|
105
|
+
</AccordionPanel>
|
|
106
|
+
<AccordionPanel>
|
|
107
|
+
The `signJwt` import path has changed from `@clerk/backend` to `@clerk/backend/tokens`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made
|
|
108
|
+
|
|
109
|
+
```diff
|
|
110
|
+
- import { signJwt } from "@clerk/backend"
|
|
111
|
+
+ import { signJwt } from "@clerk/backend/tokens"
|
|
112
|
+
```
|
|
113
|
+
</AccordionPanel>
|
|
114
|
+
<AccordionPanel>
|
|
115
|
+
The `constants` import path has changed from `@clerk/backend` to `@clerk/backend/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:
|
|
116
|
+
|
|
117
|
+
```diff
|
|
118
|
+
- import { constants } from "@clerk/backend"
|
|
119
|
+
+ import { constants } from "@clerk/backend/internal"
|
|
120
|
+
```
|
|
121
|
+
</AccordionPanel>
|
|
122
|
+
<AccordionPanel>
|
|
123
|
+
The `redirect` import path has changed from `@clerk/backend` to `@clerk/backend/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:
|
|
124
|
+
|
|
125
|
+
```diff
|
|
126
|
+
- import { redirect } from "@clerk/backend"
|
|
127
|
+
+ import { redirect } from "@clerk/backend/internal"
|
|
128
|
+
```
|
|
129
|
+
</AccordionPanel>
|
|
130
|
+
<AccordionPanel>
|
|
131
|
+
The `createAuthenticateRequest` import path has changed from `@clerk/backend` to `@clerk/backend/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:
|
|
132
|
+
|
|
133
|
+
```diff
|
|
134
|
+
- import { createAuthenticateRequest } from "@clerk/backend"
|
|
135
|
+
+ import { createAuthenticateRequest } from "@clerk/backend/internal"
|
|
136
|
+
```
|
|
137
|
+
</AccordionPanel>
|
|
138
|
+
<AccordionPanel>
|
|
139
|
+
The `createIsomorphicRequest` import path has changed from `@clerk/backend` to `@clerk/backend/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:
|
|
140
|
+
|
|
141
|
+
```diff
|
|
142
|
+
- import { createIsomorphicRequest } from "@clerk/backend"
|
|
143
|
+
+ import { createIsomorphicRequest } from "@clerk/backend/internal"
|
|
144
|
+
```
|
|
145
|
+
</AccordionPanel>
|
|
146
|
+
<AccordionPanel>
|
|
147
|
+
The `createIsomorphicRequest` import was intended for those building custom Clerk integrations for frameworks and has been moved to `@clerk/backend/internal` to reflect this. Please use caution when using internal imports as they are outside the bounds of semver.
|
|
148
|
+
|
|
149
|
+
```diff
|
|
150
|
+
- import { createIsomorphicRequest } from "@clerk/backend"
|
|
151
|
+
+ import { createIsomorphicRequest } from "@clerk/backend/internal"
|
|
152
|
+
```
|
|
153
|
+
</AccordionPanel>
|
|
154
|
+
<AccordionPanel>
|
|
155
|
+
The `SignJWTError` import path has changed from `@clerk/backend` to `@clerk/backend/errors`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made:
|
|
156
|
+
|
|
157
|
+
```diff
|
|
158
|
+
- import { SignJWTError } from "@clerk/backend"
|
|
159
|
+
+ import { SignJWTError } from "@clerk/backend/errors"
|
|
160
|
+
```
|
|
161
|
+
</AccordionPanel>
|
|
162
|
+
<AccordionPanel>
|
|
163
|
+
The `TokenVerificationError` import path has changed from `@clerk/backend` to `@clerk/backend/errors`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made:
|
|
164
|
+
|
|
165
|
+
```diff
|
|
166
|
+
- import { TokenVerificationError } from "@clerk/backend"
|
|
167
|
+
+ import { TokenVerificationError } from "@clerk/backend/errors"
|
|
168
|
+
```
|
|
169
|
+
</AccordionPanel>
|
|
170
|
+
<AccordionPanel>
|
|
171
|
+
The `TokenVerificationErrorAction` import path has changed from `@clerk/backend` to `@clerk/backend/errors`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made:
|
|
172
|
+
|
|
173
|
+
```diff
|
|
174
|
+
- import { TokenVerificationErrorAction } from "@clerk/backend"
|
|
175
|
+
+ import { TokenVerificationErrorAction } from "@clerk/backend/errors"
|
|
176
|
+
```
|
|
177
|
+
</AccordionPanel>
|
|
178
|
+
<AccordionPanel>
|
|
179
|
+
The `TokenVerificationErrorReason` import path has changed from `@clerk/backend` to `@clerk/backend/errors`. You must update your import path in order for it to work correctly. Example below of the fix that needs to be made:
|
|
180
|
+
|
|
181
|
+
```diff
|
|
182
|
+
- import { TokenVerificationErrorReason } from "@clerk/backend"
|
|
183
|
+
+ import { TokenVerificationErrorReason } from "@clerk/backend/errors"
|
|
184
|
+
```
|
|
185
|
+
</AccordionPanel>
|
|
186
|
+
</Accordion>
|
|
187
|
+
|
|
188
|
+
### `httpOptions` parameter removed
|
|
189
|
+
|
|
190
|
+
The `httpOptions` parameter was removed from the internal `buildRequest` function but it is used by most public facing APIs. Hence you were able to pass `httpOptions` to some functions which is not possible anymore. If you're currently relying on this functionality and wish to update, please reach out to Clerk's support.
|
|
191
|
+
|
|
192
|
+
The internal change looks like this:
|
|
193
|
+
|
|
194
|
+
```diff
|
|
195
|
+
- const r = buildRequest({ httpOptions: { headers: {} }})
|
|
196
|
+
+ const request = buildRequest()
|
|
197
|
+
+ request({ headerParams: {} })
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
### Removed: `orgs` claim on JWT
|
|
201
|
+
|
|
202
|
+
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.
|
|
203
|
+
|
|
204
|
+
The `orgs` claim was part of the `JwtPayload`. Here are a few examples of where the `JwtPayload` could be found.
|
|
205
|
+
|
|
206
|
+
<Accordion titles={["Next.js", "Fastify", "@clerk/backend", "@clerk/clerk-sdk-node"]} heading="h5">
|
|
207
|
+
<AccordionPanel>
|
|
208
|
+
```typescript filename="Next.js"
|
|
209
|
+
import { getAuth } from "@clerk/nextjs/server"
|
|
210
|
+
const claims: JwtPayload = getAuth(request).sessionClaims
|
|
211
|
+
|
|
212
|
+
import { getAuth } from "@clerk/ssr.server"
|
|
213
|
+
const claims: JwtPayload = (await getAuth(request)).sessionClaims
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
</AccordionPanel>
|
|
217
|
+
<AccordionPanel>
|
|
218
|
+
```typescript filename="Fastify"
|
|
219
|
+
import { getAuth } from "@clerk/fastify"
|
|
220
|
+
const claims: JwtPayload = (await getAuth(request)).sessionClaims
|
|
221
|
+
```
|
|
222
|
+
</AccordionPanel>
|
|
223
|
+
<AccordionPanel>
|
|
224
|
+
```typescript filename="@clerk/backend"
|
|
225
|
+
import { createClerkClient } from "@clerk/backend"
|
|
226
|
+
|
|
227
|
+
const clerkClient = createClerkClient({ secretKey: "" })
|
|
228
|
+
const requestState = await clerkClient.authenticateRequest(
|
|
229
|
+
request,
|
|
230
|
+
{ publishableKey: "" }
|
|
231
|
+
)
|
|
232
|
+
const claims: JwtPayload = requestState.toAuth().sessionClaims
|
|
233
|
+
```
|
|
234
|
+
|
|
235
|
+
</AccordionPanel>
|
|
236
|
+
<AccordionPanel>
|
|
237
|
+
```typescript filename="@clerk/clerk-sdk-node"
|
|
238
|
+
import { clerkClient } from "@clerk/clerk-sdk-node"
|
|
239
|
+
|
|
240
|
+
router.use((...args) => clerkClient.expressRequireAuth()(...args))
|
|
241
|
+
router.get("/me", async (req, reply: Response) => {
|
|
242
|
+
return reply.json({ auth: req.auth })
|
|
243
|
+
})
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
</AccordionPanel>
|
|
247
|
+
</Accordion>
|
|
248
|
+
|
|
249
|
+
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.
|
|
250
|
+
|
|
251
|
+
### Changes to pagination arguments for some functions
|
|
252
|
+
|
|
253
|
+
There were some changes made to pagination-related arguments passed into functions, in order to make it more clear how to control paginated results. See each function impacted by these changes below:
|
|
254
|
+
|
|
255
|
+
<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>Clients.getClientList</code> arguments changed", "<code>Sessions.getSessionList</code> arguments changed"]}>
|
|
256
|
+
<AccordionPanel>
|
|
257
|
+
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:
|
|
258
|
+
|
|
259
|
+
```diff
|
|
260
|
+
const { data } = await organization.getRoles({
|
|
261
|
+
- limit: 10,
|
|
262
|
+
+ pageSize: 10,
|
|
263
|
+
- offset: 10,
|
|
264
|
+
+ initialPage: 2,
|
|
265
|
+
})
|
|
266
|
+
```
|
|
267
|
+
</AccordionPanel>
|
|
268
|
+
<AccordionPanel>
|
|
269
|
+
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:
|
|
270
|
+
|
|
271
|
+
```diff
|
|
272
|
+
const { data } = await organization.getMemberships({
|
|
273
|
+
- limit: 10,
|
|
274
|
+
+ pageSize: 10,
|
|
275
|
+
- offset: 10,
|
|
276
|
+
+ initialPage: 2,
|
|
277
|
+
})
|
|
278
|
+
```
|
|
279
|
+
</AccordionPanel>
|
|
280
|
+
<AccordionPanel>
|
|
281
|
+
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:
|
|
282
|
+
|
|
283
|
+
```diff
|
|
284
|
+
const { data } = await organization.getDomains({
|
|
285
|
+
- limit: 10,
|
|
286
|
+
+ pageSize: 10,
|
|
287
|
+
- offset: 10,
|
|
288
|
+
+ initialPage: 2,
|
|
289
|
+
})
|
|
290
|
+
```
|
|
291
|
+
</AccordionPanel>
|
|
292
|
+
<AccordionPanel>
|
|
293
|
+
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:
|
|
294
|
+
|
|
295
|
+
```diff
|
|
296
|
+
const { data } = await organization.getInvitations({
|
|
297
|
+
- limit: 10,
|
|
298
|
+
+ pageSize: 10,
|
|
299
|
+
- offset: 10,
|
|
300
|
+
+ initialPage: 2,
|
|
301
|
+
})
|
|
302
|
+
```
|
|
303
|
+
</AccordionPanel>
|
|
304
|
+
<AccordionPanel>
|
|
305
|
+
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:
|
|
306
|
+
|
|
307
|
+
```diff
|
|
308
|
+
const { data } = await organization.getMembershipRequests({
|
|
309
|
+
- limit: 10,
|
|
310
|
+
+ pageSize: 10,
|
|
311
|
+
- offset: 10,
|
|
312
|
+
+ initialPage: 2,
|
|
313
|
+
})
|
|
314
|
+
```
|
|
315
|
+
</AccordionPanel>
|
|
316
|
+
<AccordionPanel>
|
|
317
|
+
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:
|
|
318
|
+
|
|
319
|
+
```diff
|
|
320
|
+
const { data } = await user.getOrganizationInvitations({
|
|
321
|
+
- limit: 10,
|
|
322
|
+
+ pageSize: 10,
|
|
323
|
+
- offset: 10,
|
|
324
|
+
+ initialPage: 2,
|
|
325
|
+
})
|
|
326
|
+
```
|
|
327
|
+
</AccordionPanel>
|
|
328
|
+
<AccordionPanel>
|
|
329
|
+
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:
|
|
330
|
+
|
|
331
|
+
```diff
|
|
332
|
+
const { data } = await user.getOrganizationSuggestions({
|
|
333
|
+
- limit: 10,
|
|
334
|
+
+ pageSize: 10,
|
|
335
|
+
- offset: 10,
|
|
336
|
+
+ initialPage: 2,
|
|
337
|
+
})
|
|
338
|
+
```
|
|
339
|
+
</AccordionPanel>
|
|
340
|
+
<AccordionPanel>
|
|
341
|
+
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:
|
|
342
|
+
|
|
343
|
+
```diff
|
|
344
|
+
const { data } = await user.getOrganizationMemberships({
|
|
345
|
+
- limit: 10,
|
|
346
|
+
+ pageSize: 10,
|
|
347
|
+
- offset: 10,
|
|
348
|
+
+ initialPage: 2,
|
|
349
|
+
})
|
|
350
|
+
```
|
|
351
|
+
</AccordionPanel>
|
|
352
|
+
<AccordionPanel>
|
|
353
|
+
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:
|
|
354
|
+
|
|
355
|
+
```diff
|
|
356
|
+
const { data } = await clients.getClientList({
|
|
357
|
+
- limit: 10,
|
|
358
|
+
+ pageSize: 10,
|
|
359
|
+
- offset: 10,
|
|
360
|
+
+ initialPage: 2,
|
|
361
|
+
})
|
|
362
|
+
```
|
|
363
|
+
</AccordionPanel>
|
|
364
|
+
<AccordionPanel>
|
|
365
|
+
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:
|
|
366
|
+
|
|
367
|
+
```diff
|
|
368
|
+
const { data } = await sessions.getSessionList({
|
|
369
|
+
- limit: 10,
|
|
370
|
+
+ pageSize: 10,
|
|
371
|
+
- offset: 10,
|
|
372
|
+
+ initialPage: 2,
|
|
373
|
+
})
|
|
374
|
+
```
|
|
375
|
+
</AccordionPanel>
|
|
376
|
+
</Accordion>
|
|
377
|
+
|
|
378
|
+
### Changes to some function return signatures
|
|
379
|
+
|
|
380
|
+
There have been changes to return signatures for some functions. Since Clerk's API responses are paginated, the `totalCount` property is helpful in determining the total number of items in the response easily. This change also aligns the response shape with what is returned from the Clerk backend API. Each impacted function is listed below, along with code examples:
|
|
381
|
+
|
|
382
|
+
<Accordion titles={["<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>Users.getOrganizationMembershipList</code> return signature changed"]}>
|
|
383
|
+
<AccordionPanel>
|
|
384
|
+
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.
|
|
385
|
+
|
|
386
|
+
Here's an example of how the response shape would change with this modification:
|
|
387
|
+
|
|
388
|
+
```diff
|
|
389
|
+
- const data = await clerkClient.users.getOrganizationMembershipList()
|
|
390
|
+
+ const { data, totalCount } = await clerkClient.users.getOrganizationMembershipList()
|
|
391
|
+
```
|
|
392
|
+
</AccordionPanel>
|
|
393
|
+
<AccordionPanel>
|
|
394
|
+
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.
|
|
395
|
+
|
|
396
|
+
Here's an example of how the response shape would change with this modification:
|
|
397
|
+
|
|
398
|
+
```diff
|
|
399
|
+
- const data = await clerkClient.users.getOrganizationInvitationList()
|
|
400
|
+
+ const { data, totalCount } = await clerkClient.users.getOrganizationInvitationList()
|
|
401
|
+
```
|
|
402
|
+
</AccordionPanel>
|
|
403
|
+
<AccordionPanel>
|
|
404
|
+
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:
|
|
405
|
+
|
|
406
|
+
```diff
|
|
407
|
+
const data = await clerkClient.organizations.getOrganizationInvitationList({
|
|
408
|
+
organizationId: "...",
|
|
409
|
+
})
|
|
410
|
+
|
|
411
|
+
- data.forEach(() => {})
|
|
412
|
+
+ data.data.forEach(() => {})
|
|
413
|
+
```
|
|
414
|
+
</AccordionPanel>
|
|
415
|
+
<AccordionPanel>
|
|
416
|
+
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:
|
|
417
|
+
|
|
418
|
+
```diff
|
|
419
|
+
const { user } = useUser()
|
|
420
|
+
const membershipList = user.getOrganizationMembershipList()
|
|
421
|
+
|
|
422
|
+
- membershipList.forEach(() => {})
|
|
423
|
+
+ membershipList.data.forEach(() => {})
|
|
424
|
+
```
|
|
425
|
+
</AccordionPanel>
|
|
426
|
+
<AccordionPanel>
|
|
427
|
+
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.
|
|
428
|
+
|
|
429
|
+
Here's an example of how the response shape would change with this modification:
|
|
430
|
+
|
|
431
|
+
```diff
|
|
432
|
+
- const data = await clerkClient.users.getOrganizationList()
|
|
433
|
+
+ const { data, totalCount } = await clerkClient.users.getOrganizationList()
|
|
434
|
+
```
|
|
435
|
+
</AccordionPanel>
|
|
436
|
+
<AccordionPanel>
|
|
437
|
+
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:
|
|
438
|
+
|
|
439
|
+
```diff
|
|
440
|
+
const { organization } = useOrganization()
|
|
441
|
+
const orgList = organization.getOrganizationList()
|
|
442
|
+
|
|
443
|
+
- orgList.forEach(() => {})
|
|
444
|
+
+ orgList.data.forEach(() => {})
|
|
445
|
+
```
|
|
446
|
+
</AccordionPanel>
|
|
447
|
+
<AccordionPanel>
|
|
448
|
+
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.
|
|
449
|
+
|
|
450
|
+
Here's an example of how the response shape would change with this modification:
|
|
451
|
+
|
|
452
|
+
```diff
|
|
453
|
+
- const data = await clerkClient.invitations.getInvitationList()
|
|
454
|
+
+ const { data, totalCount } = await clerkClient.invitations.getInvitationList()
|
|
455
|
+
```
|
|
456
|
+
</AccordionPanel>
|
|
457
|
+
<AccordionPanel>
|
|
458
|
+
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.
|
|
459
|
+
|
|
460
|
+
Here's an example of how the response shape would change with this modification:
|
|
461
|
+
|
|
462
|
+
```diff
|
|
463
|
+
- const data = await clerkClient.sessions.getSessionList()
|
|
464
|
+
+ const { data, totalCount } = await clerkClient.sessions.getSessionList()
|
|
465
|
+
```
|
|
466
|
+
</AccordionPanel>
|
|
467
|
+
<AccordionPanel>
|
|
468
|
+
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.
|
|
469
|
+
|
|
470
|
+
Here's an example of how the response shape would change with this modification:
|
|
471
|
+
|
|
472
|
+
```diff
|
|
473
|
+
- const data = await clerkClient.users.getUserList()
|
|
474
|
+
+ const { data, totalCount } = await clerkClient.users.getUserList()
|
|
475
|
+
```
|
|
476
|
+
</AccordionPanel>
|
|
477
|
+
<AccordionPanel>
|
|
478
|
+
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.
|
|
479
|
+
|
|
480
|
+
Here's an example of how the response shape would change with this modification:
|
|
481
|
+
|
|
482
|
+
```diff
|
|
483
|
+
- const data = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
|
|
484
|
+
+ const { data, totalCount } = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList()
|
|
485
|
+
```
|
|
486
|
+
</AccordionPanel>
|
|
487
|
+
<AccordionPanel>
|
|
488
|
+
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.
|
|
489
|
+
|
|
490
|
+
Here's an example of how the response shape would change with this modification:
|
|
491
|
+
|
|
492
|
+
```diff
|
|
493
|
+
- const data = await clerkClient.clients.getClientList()
|
|
494
|
+
+ const { data, totalCount } = await clerkClient.allowlistIdentifiers.getClientList()
|
|
495
|
+
```
|
|
496
|
+
</AccordionPanel>
|
|
497
|
+
<AccordionPanel>
|
|
498
|
+
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.
|
|
499
|
+
|
|
500
|
+
Here's an example of how the response shape would change with this modification:
|
|
501
|
+
|
|
502
|
+
```diff
|
|
503
|
+
- const data = await clerkClient.redirectUrls.getRedirectUrlList()
|
|
504
|
+
+ const { data, totalCount } = await clerkClient.redirectUrls.getRedirectUrlList()
|
|
505
|
+
```
|
|
506
|
+
</AccordionPanel>
|
|
507
|
+
<AccordionPanel>
|
|
508
|
+
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.
|
|
509
|
+
|
|
510
|
+
Here's an example of how the response shape would change with this modification:
|
|
511
|
+
|
|
512
|
+
```diff
|
|
513
|
+
- const data = await clerkClient.users.getUserOauthAccessToken()
|
|
514
|
+
+ const { data, totalCount } = await clerkClient.users.getUserOauthAccessToken()
|
|
515
|
+
```
|
|
516
|
+
</AccordionPanel>
|
|
517
|
+
<AccordionPanel>
|
|
518
|
+
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.
|
|
519
|
+
|
|
520
|
+
Here's an example of how the response shape would change with this modification:
|
|
521
|
+
|
|
522
|
+
```diff
|
|
523
|
+
- const data = await clerkClient.users.getOrganizationMembershipList()
|
|
524
|
+
+ const { data, totalCount } = await clerkClient.users.getOrganizationMembershipList()
|
|
525
|
+
```
|
|
526
|
+
</AccordionPanel>
|
|
527
|
+
</Accordion>
|
|
528
|
+
|
|
529
|
+
### Image URL Name Consolidation
|
|
530
|
+
|
|
531
|
+
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:
|
|
532
|
+
|
|
533
|
+
<Accordion titles={["<code>Organization.logoUrl</code> -> <code>Organization.imageUrl</code>", "<code>User.profileImageUrl</code> -> <code>.imageUrl</code>", "<code>ExternalAccount.picture</code> -> <code>.imageUrl</code>", "<code>ExternalAccountJSON.avatar_url</code> -> <code>.imageUrl</code>", "<code>OrganizationJSON.logo_url</code> -> <code>.imageUrl</code>", "<code>UserJSON.profile_image_url</code> -> <code>.imageUrl</code>", "<code>OrganizationMembershipPublicUserData.profileImageUrl</code> -> <code>.imageUrl</code>", "<code>OrganizationMembershipPublicUserDataJSON.profile_image_url</code> -> <code>.imageUrl</code>"]}>
|
|
534
|
+
<AccordionPanel>
|
|
535
|
+
The `logoUrl` property of any [`Organization` object](https://clerk.com/docs/references/javascript/organization/organization#organization) has been changed to `imageUrl`.
|
|
536
|
+
</AccordionPanel>
|
|
537
|
+
<AccordionPanel>
|
|
538
|
+
The `profileImageUrl` property of any `User` object has been changed to `imageUrl`.
|
|
539
|
+
</AccordionPanel>
|
|
540
|
+
<AccordionPanel>
|
|
541
|
+
The `picture` property of any [`ExternalAcccount` object](https://clerk.com/docs/references/javascript/external-account) has been changed to `imageUrl`.
|
|
542
|
+
</AccordionPanel>
|
|
543
|
+
<AccordionPanel>
|
|
544
|
+
The `avatarUrl` property of any `ExternalAcccountJSON` object has been changed to `imageUrl`.
|
|
545
|
+
</AccordionPanel>
|
|
546
|
+
<AccordionPanel>
|
|
547
|
+
The `logo_url` property of any `OrganizationJSON` object has been changed to `imageUrl`.
|
|
548
|
+
</AccordionPanel>
|
|
549
|
+
<AccordionPanel>
|
|
550
|
+
The `profile_image_url` property of any `UserJSON` object has been changed to `imageUrl`.
|
|
551
|
+
</AccordionPanel>
|
|
552
|
+
<AccordionPanel>
|
|
553
|
+
The `profileImageUrl` property of any `OrganizationMembershipPublicUserData` object has been changed to `imageUrl`.
|
|
554
|
+
</AccordionPanel>
|
|
555
|
+
<AccordionPanel>
|
|
556
|
+
The `profile_image_url` property of any `OrganizationMembershipPublicUserDataJSON` object has been changed to `imageUrl`.
|
|
557
|
+
</AccordionPanel>
|
|
558
|
+
</Accordion>
|
|
559
|
+
|
|
560
|
+
### Deprecation removals & housekeeping
|
|
561
|
+
|
|
562
|
+
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.
|
|
563
|
+
|
|
564
|
+
<Callout type='info'>
|
|
565
|
+
For this section more than any other one, please use the CLI upgrade tool (`npx @clerk/upgrade`). Changes in this
|
|
566
|
+
section are very unlikely to appear in your codebase, the tool will save time looking for them.
|
|
567
|
+
</Callout>
|
|
568
|
+
|
|
569
|
+
#### Deprecation removals
|
|
570
|
+
|
|
571
|
+
<Accordion titles={["<code>User.update({ password: 'x' })</code> -> <code>User.updatePassword('x')</code>", "<code>frontendApi</code> -> <code>publishableKey</code> as param to createClerkClient", "<code>apiKey</code> -> <code>secretKey</code> as param to createClerkClient"]}>
|
|
572
|
+
<AccordionPanel>
|
|
573
|
+
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:
|
|
574
|
+
|
|
575
|
+
```diff
|
|
576
|
+
- user.update({ password: 'foo' });
|
|
577
|
+
|
|
578
|
+
+ user.updatePassword({
|
|
579
|
+
+ currentPassword: 'bar',
|
|
580
|
+
+ newPassword: 'foo',
|
|
581
|
+
+ signOutOfOtherSessions: true,
|
|
582
|
+
+ });
|
|
583
|
+
```
|
|
584
|
+
</AccordionPanel>
|
|
585
|
+
<AccordionPanel>
|
|
586
|
+
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. Also note that the import value has changed for creating a new Clerk client, which will be addressed by a separate line item if relevant to your codebase.
|
|
587
|
+
|
|
588
|
+
```diff
|
|
589
|
+
- import { Clerk } from '@clerk/backend';
|
|
590
|
+
+ import { createClerkClient } from '@clerk/backend';
|
|
591
|
+
|
|
592
|
+
- const clerkClient = Clerk({ frontendApi: '...' });
|
|
593
|
+
+ const clerkClient = createClerkClient({ publishableKey: '...' });
|
|
594
|
+
|
|
595
|
+
- clerkClient.authenticateRequest({ frontendApi: '...' });
|
|
596
|
+
+ clerkClient.authenticateRequest({ publishableKey: '...' });
|
|
597
|
+
```
|
|
598
|
+
</AccordionPanel>
|
|
599
|
+
<AccordionPanel>
|
|
600
|
+
The `apiKey` argument passed to `createClerkClient` must be changed to `secretKey`. Also note that the import value has changed for creating a new Clerk client, which will be addressed by a separate line item if relevant to your codebase.
|
|
601
|
+
|
|
602
|
+
```diff
|
|
603
|
+
- import { Clerk } from '@clerk/backend';
|
|
604
|
+
+ import { createClerkClient } from '@clerk/backend';
|
|
605
|
+
|
|
606
|
+
- const clerkClient = Clerk({ apiKey: '...' });
|
|
607
|
+
+ const clerkClient = createClerkClient({ secretKey: '...' });
|
|
608
|
+
|
|
609
|
+
- clerkClient.authenticateRequest({ apiKey: '...' });
|
|
610
|
+
+ clerkClient.authenticateRequest({ secretKey: '...' });
|
|
611
|
+
```
|
|
612
|
+
</AccordionPanel>
|
|
613
|
+
</Accordion>
|
|
614
|
+
|
|
615
|
+
#### Other Breaking changes
|
|
616
|
+
|
|
617
|
+
<Accordion titles={["<code>API_URL</code> value has changed", "<code>Clerk</code> -> <code>createClerkClient</code>", "<code>pkgVersion</code> -> <code>clerkJSVersion</code>", "<code>clerkClient.__unstable_options</code> removed", "<code>createEmail</code> import removed", "<code>MembershipRole</code> type replaced by <code>OrganizationCustomRoleKey</code> type", "<code>buildRequestUrl</code> import removed", "<code>Organization.members_count</code> -> <code>Organization.membersCount</code>"]}>
|
|
618
|
+
<AccordionPanel>
|
|
619
|
+
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.
|
|
620
|
+
</AccordionPanel>
|
|
621
|
+
<AccordionPanel>
|
|
622
|
+
The top level `Clerk` import was renamed to `createClerkClient`. This is just a name change and can be treated as a text replacement, no changes to the params or return types.
|
|
623
|
+
|
|
624
|
+
```js
|
|
625
|
+
// before
|
|
626
|
+
import { Clerk } from '@clerk/backend';
|
|
627
|
+
|
|
628
|
+
// after
|
|
629
|
+
import { createClerkClient } from '@clerk/backend';
|
|
630
|
+
```
|
|
631
|
+
</AccordionPanel>
|
|
632
|
+
<AccordionPanel>
|
|
633
|
+
The `pkgVersion` parameter was removed from the `loadInterstitialFromLocal`, `loadInterstitialFromBAPI`, and `buildPublicInterstitialUrl` functions. Use `clerkJSVersion` instead. Example:
|
|
634
|
+
|
|
635
|
+
```diff
|
|
636
|
+
- loadInterstitialFromLocal({ pkgVersion: "..." })
|
|
637
|
+
+ loadInterstitialFromLocal({ clerkJSVersion: "..." })
|
|
638
|
+
```
|
|
639
|
+
</AccordionPanel>
|
|
640
|
+
<AccordionPanel>
|
|
641
|
+
The `clerkClient.__unstable_options` property was removed. Previously, you could use it to update the internal options. Instead, create a new ` clerkClient` instance using `createClerkClient` and pass the options in this way. For example:
|
|
642
|
+
|
|
643
|
+
```diff
|
|
644
|
+
import { createClerkClient } from "@clerk/backend"
|
|
645
|
+
|
|
646
|
+
const clerkClient = createClerkClient({ secretKey: "old" })
|
|
647
|
+
|
|
648
|
+
- clerkClient.__unstable_options.secretKey = "new"
|
|
649
|
+
+ const newClerkClient = createClerkClient({ secretKey: "new" })
|
|
650
|
+
```
|
|
651
|
+
</AccordionPanel>
|
|
652
|
+
<AccordionPanel>
|
|
653
|
+
The `createEmail` import has been removed. There is no replacement at this time because we need to rethink how `createEmail` behaves and align it with the newer `sendSms` method. If this is an issue for your implementation, please contact [Clerk support](https://clerk.com/contact).
|
|
654
|
+
</AccordionPanel>
|
|
655
|
+
<AccordionPanel>
|
|
656
|
+
The `MembershipRole` type was replaced with `OrganizationCustomRoleKey` (related to [roles and permissions](https://clerk.com/docs/organizations/roles-permissions)). An example of where this type might be found:
|
|
657
|
+
|
|
658
|
+
```js
|
|
659
|
+
import { useAuth } from '@clerk/clerk-react';
|
|
660
|
+
|
|
661
|
+
const { orgRole } = useAuth();
|
|
662
|
+
```
|
|
663
|
+
|
|
664
|
+
To support the existing roles `admin`, `basic_member`, and `guest_member` apply interface merging using the following snippet:
|
|
665
|
+
|
|
666
|
+
```js
|
|
667
|
+
interface ClerkAuthorization {
|
|
668
|
+
permission: ''
|
|
669
|
+
role: 'admin' | 'basic_member' | 'guest_member'
|
|
670
|
+
}
|
|
671
|
+
```
|
|
672
|
+
</AccordionPanel>
|
|
673
|
+
<AccordionPanel>
|
|
674
|
+
The `buildRequestUrl` import was intended for those building custom Clerk integrations for frameworks and has been removed in favor of other methods internally. If you were relying on this function and this is an issue, please [reach out to Clerk support](https://clerk.com/support).
|
|
675
|
+
</AccordionPanel>
|
|
676
|
+
<AccordionPanel>
|
|
677
|
+
The `members_count` attribute of the `Organization` resource has been renamed to `membersCount` to match the naming convention of other attributes.
|
|
678
|
+
|
|
679
|
+
```diff
|
|
680
|
+
- organization.members_count
|
|
681
|
+
+ organization.membersCount
|
|
682
|
+
```
|
|
683
|
+
</AccordionPanel>
|
|
684
|
+
</Accordion>
|
|
685
|
+
|
|
686
|
+
|
|
687
|
+
|