# Upgrading @clerk/clerk-js to Core 2 Core 2 is included in the Javascript SDK starting with version 5. 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. By the end of this guide, you'll have successfully upgraded your JS project to use `@clerk/clerk-js` 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. ## Preparing to upgrade Before upgrading, it's highly recommended that you update your Clerk SDKs to the latest Core 1 version (`npm i @clerk/clerk-js@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. Additionally, some of the minimum 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. ## Updating to Core 2 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. ```npm npm install @clerk/clerk-js ``` ## CLI upgrade helper 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. To run the CLI tool, navigate to your project and run it in the terminal: ```npm npx @clerk/upgrade --from=core-1 ``` 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. ## Breaking Changes ### Component design adjustments The new version ships with improved design and UX across all of Clerk's [UI components](https://clerk.com/docs/reference/components/overview.md). If you have used the [appearance prop](https://clerk.com/docs/guides/customizing-clerk/appearance-prop/overview.md) or tokens for a [custom theme](https://clerk.com/docs/guides/customizing-clerk/appearance-prop/overview.md), you will likely need to make some adjustments to ensure your styling is still looking great. If you're using the [localization prop](https://clerk.com/docs/guides/customizing-clerk/localization.md) you will likely need to make adjustments to account for added or removed localization keys. [More detail on these changes »](https://clerk.com/docs/guides/development/upgrading/upgrade-guides/core-2.md#component-redesign) ### After sign up/in/out default value change In Core 2, defining redirect URLs for after sign-up, sign-in, or sign-out via the Clerk Dashboard has been removed. Previously, the "Paths" section in the Clerk Dashboard included "Component paths" where URLs could be defined, accompanied by a deprecation warning. This functionality is now removed, and specifying redirect paths via the dashboard is no longer supported. If you need to pass a redirect URL for after sign-up, sign-in, or sign-out, there are [several ways to achieve this](https://clerk.com/docs/guides/development/customize-redirect-urls.md), including environment variables, middleware, or passing them directly to the relevant components. 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. ```jsx ``` ### `afterSignXUrl` changes > This section refers to `afterSignXUrl` where `X` could be `Up` or `In` depending on the context. All `afterSignXUrl` props and `CLERK_AFTER_SIGN_X_URL` environment variables have been deprecated, and should be replaced by one of the following options: - `CLERK_SIGN_X_FORCE_REDIRECT_URL` / `signXForceRedirectUrl` – 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. - `CLERK_SIGN_X_FALLBACK_REDIRECT_URL` / `signXFallbackRedirectUrl` – If set, this will mirror the previous behavior, only redirecting to the provided URL if there is no `redirect_url` in the querystring. In general, use the environment variables over the props. > If neither value is set, Clerk will redirect to the `redirect_url` if present, otherwise it will redirect to `/`. To retain the current behavior of your app without any changes, you can switch `afterSignXUrl` with `signXFallbackRedirectUrl` as such: ```jsx ``` #### Why this is changing To make redirect behavior more clear and predictable, Clerk is changing the way "after sign up/in url"s and redirect url props are handled in Core 2. The `afterSignXUrl` props and `CLERK_AFTER_SIGN_X_URL` environment variables behave differently based on how a user reaches a sign up/in page: - **Via a link** – When users visit a sign up/in page via a link, Clerk sets the previous page URL to a `redirect_url` querystring. When done signing up/in, these users are redirected to the previous page, and the `CLERK_AFTER_SIGN_X_URL` variables are ignored. This is a common sign up/in flow pattern that interrupts the user's navigation the least. - **Direct navigation** – When users navigate directly to a sign up/in page, no value is set to `redirect_url` and the appropriate `CLERK_AFTER_SIGN_X_URL` is used. Overall, this behavior is unintuitive and doesn't give a way to force a redirect after sign up/in, so the behavior is changing. ### Removed: `orgs` claim on JWT 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. The `orgs` claim was part of the `JwtPayload`. Here are a few examples of where the `JwtPayload` could be found. filename: Next.js ```typescript import { getAuth } from '@clerk/nextjs/server' const claims: JwtPayload = getAuth(request).sessionClaims import { getAuth } from '@clerk/ssr.server' const claims: JwtPayload = (await getAuth(request)).sessionClaims ``` filename: Fastify ```typescript import { getAuth } from '@clerk/fastify' const claims: JwtPayload = (await getAuth(request)).sessionClaims ``` filename: @clerk/backend ```typescript import { createClerkClient } from '@clerk/backend' const clerkClient = createClerkClient({ secretKey: '' }) const requestState = await clerkClient.authenticateRequest(request, { publishableKey: '' }) const claims: JwtPayload = requestState.toAuth().sessionClaims ``` > The Node SDK is no longer supported. [Upgrade to the Express SDK](https://clerk.com/docs/guides/development/upgrading/upgrade-guides/node-to-express.md). filename: @clerk/clerk-sdk-node ```typescript import { clerkClient } from '@clerk/clerk-sdk-node' router.use((...args) => clerkClient.expressRequireAuth()(...args)) router.get('/me', async (req, reply: Response) => { return reply.json({ auth: req.auth }) }) ``` If you would like to have your JWT return all of the user's organizations, you can create a [custom JWT template](https://clerk.com/docs/guides/sessions/jwt-templates.md) in your dashboard. Add `{ "orgs": "user.organizations" }` to it. ### Path routing is now the default On components like [](https://clerk.com/docs/reference/components/authentication/sign-in.md) you can define the props `routing` and `path`. `routing` can be set to `'hash' | 'path'` and describes the routing strategy that should be used. `path` defines where the component is mounted when `routing="path"` is used. Learn more about [Clerk routing](https://clerk.com/docs/guides/how-clerk-works/routing.md). In Core 2, 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: - `` - `` - `` - `` - `` Here's how you'd use the components going forward: ```jsx ``` If you don't define the `path` prop an error will be thrown. Of course, you can still use `routing="hash"` or `routing="virtual"`. ```jsx ``` ### Image URL Name Consolidation 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: The `logoUrl` property of any [Organization object](https://clerk.com/docs/reference/objects/organization.md) has been changed to `imageUrl`. The `profileImageUrl` property of any `User` object has been changed to `imageUrl`. The `avatarUrl` property of any [ExternalAccount object](https://clerk.com/docs/reference/types/external-account.md) has been changed to `imageUrl`. The `profileImageUrl` property of any `OrganizationMembershipPublicUserData` object has been changed to `imageUrl`. ### Changes to pagination arguments for some functions 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: 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: ```js const { data } = await organization.getRoles({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await organization.getMemberships({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await organization.getDomains({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await organization.getInvitations({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await organization.getMembershipRequests({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await user.getOrganizationInvitations({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await user.getOrganizationSuggestions({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` 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: ```js const { data } = await user.getOrganizationMemberships({ limit: 10, pageSize: 10, offset: 10, initialPage: 2, }) ``` ### Changes to some function return signatures There have been changes to return signatures for some functions. Since the Clerk 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: 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.users.getOrganizationMembershipList() const { data, totalCount } = await clerkClient.users.getOrganizationMembershipList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.users.getOrganizationInvitationList() const { data, totalCount } = await clerkClient.users.getOrganizationInvitationList() ``` The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since the Clerk 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: ```js const data = await clerkClient.organizations.getOrganizationInvitationList({ organizationId: '...', }) data.forEach(() => {}) data.data.forEach(() => {}) ``` The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since the Clerk 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: ```js const { user } = useUser() const membershipList = user.getOrganizationMembershipList() membershipList.forEach(() => {}) membershipList.data.forEach(() => {}) ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.users.getOrganizationList() const { data, totalCount } = await clerkClient.users.getOrganizationList() ``` The return type for this function was previously `[Items]` but has now been updated to `{ data: [Items], totalCount: number }`. Since the Clerk 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: ```js const { organization } = useOrganization() const orgList = organization.getOrganizationList() orgList.forEach(() => {}) orgList.data.forEach(() => {}) ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.invitations.getInvitationList() const { data, totalCount } = await clerkClient.invitations.getInvitationList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.sessions.getSessionList() const { data, totalCount } = await clerkClient.sessions.getSessionList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.users.getUserList() const { data, totalCount } = await clerkClient.users.getUserList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList() const { data, totalCount } = await clerkClient.allowlistIdentifiers.getAllowlistIdentifierList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.clients.getClientList() const { data, totalCount } = await clerkClient.allowlistIdentifiers.getClientList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.redirectUrls.getRedirectUrlList() const { data, totalCount } = await clerkClient.redirectUrls.getRedirectUrlList() ``` 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. Here's an example of how the response shape would change with this modification: ```js const data = await clerkClient.users.getUserOauthAccessToken() const { data, totalCount } = await clerkClient.users.getUserOauthAccessToken() ``` ### Deprecation removals & housekeeping As part of this major version, a number of previously deprecated props, arguments, 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. > For this section more than any other one, use the CLI upgrade tool (`npx @clerk/upgrade`). Changes in this > section are very unlikely to appear in your codebase, the tool will save time looking for them. #### Deprecation removals If you are updating a user's password via the [User.update method](https://clerk.com/docs/reference/objects/user.md#update), it must be changed to [User.updatePassword](https://clerk.com/docs/reference/objects/user.md#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: ```js user.update({ password: 'foo' }) user.updatePassword({ currentPassword: 'bar', newPassword: 'foo', signOutOfOtherSessions: true, }) ``` The experimental property `Clerk.experimental_canUseCaptcha` has been removed. There is no replacement for this functionality currently. If this is problematic for your application, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}! The experimental property `Clerk.experimental_captchaURL` has been removed. There is no replacement for this functionality currently. If this is problematic for your application, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}! The experimental property `Clerk.experimental_captchaSiteKey` has been removed. There is no replacement for this functionality currently. If this is problematic for your application, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}! The `Clerk.__unstable__invitationUpdate` experimental property has been removed, and has no current replacement. If this is an issue in your codebase, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}! The `Clerk.__unstable__membershipUpdate` experimental property has been removed, and has no current replacement. If this is an issue in your codebase, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}! The param `redirect_url` of [User.createExternalAccount](https://clerk.com/docs/reference/objects/user.md#create-external-account) has been updated to `redirectUrl`. This is a simple text replacement without any signature changes. The `generatedSignature` param to [Signup.attemptWeb3WalletVerification()](https://clerk.com/docs/reference/objects/sign-up.md#attempt-web3-wallet-verification) has been removed. Instead, use the `signature` param. Note that this param takes a string, where the `generatedSignature` param took a function, so both key and value will need to change. ```js // before s.attemptWeb3WalletVerification({ generatedSignature: async () => 'signatureString', }) // after s.attemptWeb3WalletVerification({ signature: 'signatureString' }) // or, if you still need to fetch the signature async const signatureString = await (async () => 'signatureString') s.attemptWeb3WalletVerification({ signature: signatureString }) ``` #### Other Breaking changes `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](https://clerk.com/docs/reference/objects/clerk.md#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: ```js await setSession('sessionID', () => void) await setActive({ session: 'sessionID', beforeEmit: () => void }) await setSession(sessionObj) await setActive({ session: sessionObj }) await setSession(sessionObj, () => void) await setActive({ session: sessionObj, beforeEmit: () => void }) ``` `setActive` also supports setting an Active Organization: ```js await setActive({ session: 'sessionID', organization: 'orgID', beforeEmit: () => void, }) await setActive({ session: sessionObj, organization: orgObj, beforeEmit: () => void, }) ``` Passing a string as an argument to `Organization.create` is no longer possible - instead, pass an object with the `name` property. ```js Organization.create('...') Organization.create({ name: '...' }) ``` The `Organization.getPendingInvitations()` method has been removed. You can use `Organization.getInvitations` instead. ```js Organization.getPendingInvitations() Organization.getInvitations({ status: 'pending' }) ``` Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects the functionality. Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects the functionality. Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects the functionality. Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects functionality. Across Clerk's documentation and codebases the term "magic link" was changed to "email link" as it more accurately reflects functionality. The `profileImageUrl` property of any [User object](https://clerk.com/docs/reference/objects/user.md) or [`OrganizationMembershipPublicData` object](https://github.com/clerk/javascript/blob/37f36e538d8879981f76f4a433066e057afb06de/packages/backend/src/api/resources/OrganizationMembership.ts#L31) has been changed to `imageUrl`. The `getOrganizationMemberships` [method on the Clerk class](https://clerk.com/docs/reference/objects/clerk.md) has been removed. Instead, use `getOrganizationMemberships` on a user instance. ```js Clerk.getOrganizationMemberships() user.getOrganizationMemberships() ``` If you are using [Clerk.addListener](https://clerk.com/docs/reference/objects/clerk.md#add-listener) or `OrganizationContext` and rely on the `lastOrganizationInvitation` and/or `lastOrganizationMember` emitted events, these properties have been removed because they were only relevant for internal use. There is no replacement for this functionality at the moment. If this affects your integration, [contact support](https://clerk.com/contact/support){{ target: '_blank' }}. The `Clerk.redirectToHome` method has been removed. If you are looking for a generic replacement for this method, you can instead use `window.Clerk.redirectToAfterSignUp()` or `window.Clerk.redirectAfterSignIn()`. To set the `afterSignUpUrl` or `afterSignInUrl`, you can: - If not using a react-based SDK, pass the values into `Clerk.load` as such: `Clerk.load({ afterSignUpUrl: 'x', afterSignInUrl: 'y' })` - If using a React-based SDK, pass the desired values into [](https://clerk.com/docs/reference/components/clerk-provider.md#properties). - If using the Next.js SDK, set with `NEXT_PUBLIC_CLERK_SIGN_IN_FALLBACK_REDIRECT_URL` or `NEXT_PUBLIC_CLERK_SIGN_UP_FALLBACK_REDIRECT_URL` - If using remix SDK, set with `CLERK_SIGN_IN_FALLBACK_REDIRECT_URL` or `CLERK_SIGN_UP_FALLBACK_REDIRECT_URL` We have removed the `Clerk.isReady()` function - instead, use the `Clerk.loaded` property to check whether Clerk has completed loading. The `signOutCallback` prop on the [ component](https://clerk.com/docs/reference/components/unstyled/sign-out-button.md) has been removed. Instead, you can use the `redirectUrl` prop. Example below: ```jsx import { SignOutButton } from '@clerk/clerk-react' export const Signout = () => { return ( { window.location.href = '/your-path' }} redirectUrl="/your-path" > ) } ``` The top level `Clerk` import was changed to a named export, like `{ Clerk }`. This is just a name change and can be treated as a text replacement, no changes to the params or return types. ```js import Clerk from '@clerk/clerk-js' import { Clerk } from '@clerk/clerk-js' ``` --- ## Sitemap [Overview of all docs pages](https://clerk.com/docs/llms.txt)