Clerk Core 2 Beta Feedback Thread

[jescalan]

On February 29th, we released the beta version of Clerk Core 2, a major update to all of our SDKs. If you have had the chance to try it out, please feel free to leave feedback here. Thank you so much!

Edit on April 19th: We've released Core 2 as GA. Learn more!

[stx-chris]

Great work! The migration CLI was very helpful. I noted, though, that the type UserJSON is not exported anymore, which is required for user-related webhook messages.

[jescalan]

It should be available from @clerk/types here I think: https://github.com/clerk/javascript/blob/main/packages/types/src/json.ts#L184

[stx-chris]

Indeed, thanks for the hint. The only issue is now that two different versions of UserJSON are exported and I have trouble casting these types, maybe some regression?

@clerk/types/dist/JSON.d.ts - with deprecations (e.g. profile_image_url)

@clerk/backend/dist/api/resources/JSON.d.ts - used by WebhookEvent

[nikosdouvlis]

Hello everyone,
The @clerk/types package holds mostly types used by clerk-js and the other client-side libraries. @stx-chris is looking for the server-side types, which currently live in @clerk/backend.

We decided not to export these in v5 as these describe the DTOs used by the package internally and most of the time people are using the instantiated resources from utils like apiClient.users.getUser.

If using webhooks, the standard approach is the following

import type { WebhookEvent } from "@clerk/nextjs/server"

const handler = req => {
  const evt = req.body.evt as WebhookEvent;
  switch (evt.type) {
    case 'user.created':
      // evt.data is of type UserJSON
  }
}

In the snippet above, evt.data is in fact UserJSON but the type is inferred automatically without the need to import UserJSON directly.

It seems that our assumption was wrong - people do want to use these directly so we'll get this changed as soon as possible (Monday 11 Mar is a realistic release date for the next beta version). It'd be great if you could share your use case so we understand the need better - is there maybe another API we can provide here to avoid the need to use these helpers directly?

Many thanks for the report :) I'll update the thread here once the fix is out.

[gabrielmaldi]

@nikosdouvlis, thanks! Any plans to also export UserWebhookEvent and others?

[stx-chris]

Hi @nikosdouvlis, we have a couple of webhooks attached and don't want to clutter the main handler file. Therefore, we keep the individual action handlers in separate files. They thus need the typed evt.data, e.g. handleUserCreated(user: UserJSON), in their functional declaration. Currently we cast to any to avoid TS errors, but it would be more convenient to use the type directly.

[emersonh-xyz]

Upgrading to Core 2 was a breeze, really enjoying all the changes so far!

I am running into an issue with sign-ups through email.

When I sign up via email through my dedicated sign-up page, I'm redirected to the route
/verify-email-address which doesn't exist in my app.

Is there a way to use a Clerk component to show the verification steps? or should it have kept me on /auth/sign-up.

EDIT
Looks like I was able to resolve this issue by defining a routing strategy for the Sign Up component. Adding either routing="hash" or routing="virtual" to the component, led to the verification window popping up within my page and didn't cause a 404.

export default function SignUpPage() {
    return (
        <>
            <SignUp routing="virtual" />
        </>
    )
}

``

[amp127]

(https://beta.clerk.com/docs/upgrade-guides/core-2/nextjs#middleware-auth-config)

I think you guys should definitely fix this to be admin instead of org admin, or at least update the comment. It caused me to waste time to figure out that if i switched to a org that i was not a admin to i lost admin access to all my true admin access. I was using a org switcher in my admin area so it really made for a runaround. What's more confusing is it results in a 404 error. I think most people were using it middleware to protect normal account admin which is far more dangerous.

[nikosdouvlis]

@emersonh-xyz Hello there, I'm forwarding this to the engineering team but I'd like some more details if possible:

• Are you using NextJS and if yes, are you using App Router or Pages Router?
• Can you post the snippet that was broken? Was it simply <SignUp />? without the routing prop?
• Can you share any Clerk-related env variables (please remove your keys before sharing)
  Thanks!

@amp127
This looks like a different issue. I'll forward it to the appropriate team immediately, but you might want to post it in a separate thread to avoid confusion. :) Regarding your comment about 404 - did you expect a 403 to be returned instead of something else entirely?

[nikosdouvlis]

Update regarding the 404 code - vercel/next.js#63302 introduces a NextJS forbidden() helper that will allow us to return 403 instead of 404. If the above PR is merged, we will also open another one to introduce unauthorized() (the equivalent helper for 401 responses).

Unfortunately, we cannot delay the Core-2 GA release until these are merged so Core-2 will use 404 for now. We plan to revise this when NextJS makes more options available to us.

[chribjel]

Loving the beta!🙏 We are daring, and use it in production in an app currently.

When can we expect the official release?

[nakanoasaservice]

The Beta version of Clerk is very easy to use for me.

I found the following type importing error in @clerk/[email protected].

Cannot find module '~ui/Components' or its corresponding type declarations.ts(2307)

[nikosdouvlis]

Hello @nakanoasaservice, glad to hear you like the beta so far :)
I will check the issue and post details once I have them. In the meantime, could you please share a few more details about your use case so I can understand your use case better? For example, do you import clerk-js in an Expo app or something similar?
Thank you

[nikosdouvlis]

This is fixed and will be deployed with our next release, thanks for reporting!

[itsMapleLeaf]

I posted an issue here about a problem with the ClerkRequest class, and I'll repost some of it here.

---

Reproduction:

git clone https://github.com/itsMapleLeaf/clerk-beta-remix-vercel-bug
cd clerk-beta-remix-vercel-bug
npx vercel deploy

The app crashes at runtime with the following error:

TypeError: Failed to parse URL from [object Request]
    at new Request (node:internal/deps/undici/undici:5855:19)
    at new ClerkRequest (/var/task/node_modules/@clerk/backend/dist/internal.js:2213:5)
    ... 6 lines matching cause stack trace ...
    at runHandler (/var/task/node_modules/@remix-run/server-runtime/node_modules/@remix-run/router/dist/router.cjs.js:4110:26)
    at callLoaderOrAction (/var/task/node_modules/@remix-run/server-runtime/node_modules/@remix-run/router/dist/router.cjs.js:4166:22) {
  [cause]: TypeError: Invalid URL
      at new URL (node:internal/url:775:36)
      at new Request (node:internal/deps/undici/undici:5853:25)
      at new ClerkRequest (/var/task/node_modules/@clerk/backend/dist/internal.js:2213:5)
      at createClerkRequest (/var/task/node_modules/@clerk/backend/dist/internal.js:2247:54)
      at loadOptions (/var/task/node_modules/@clerk/remix/dist/ssr/loadOptions.js:34:63)
      at rootAuthLoader (/var/task/node_modules/@clerk/remix/dist/ssr/rootAuthLoader.js:33:60)
      at loader$1 (file:///var/task/build/server/nodejs-eyJydW50aW1lIjoibm9kZWpzIn0/index.js:227:28)
      at Object.callRouteLoaderRR (/var/task/node_modules/@remix-run/server-runtime/dist/data.js:52:22)
      at commonRoute.loader (/var/task/node_modules/@remix-run/server-runtime/dist/routes.js:54:20)
      at runHandler (/var/task/node_modules/@remix-run/server-runtime/node_modules/@remix-run/router/dist/router.cjs.js:4110:26) {
    code: 'ERR_INVALID_URL',
    input: '[object Request]'
  }
}

The reproduction here is specifically in the case of Vercel + Remix, but I think the root of the issue is the ClerkRequest class.

Here's what happens:

1. @clerk/backend is imported, and this class is defined, extending the Request global from Node.js/undici
2. Vercel (or any other naïve server file) calls installGlobals() and replaces the global Request with the one from Remix
3. At runtime, a Remix Request gets passed into a ClerkRequest
4. Via super(), ClerkRequest passes the Remix Request to the Node.js Request
5. Node.js doesn't recognize the request instance, so it blindly tries to stringify it and parse it as URL
6. 💥

If possible, the code should change to not rely on a class whose identity is locked at definition time.

[nikosdouvlis]

Hello @itsMapleLeaf, thanks for the report. This is probably related to nodejs/undici#2155 - I will take a look within the next few hours and update the thread here with details.

[nikosdouvlis]

👋🏻 @itsMapleLeaf
Could you please try again after updating to the latest beta by running npm i @clerk/remix@beta?
The fix was included in #3129 and validated by e2e tests and by manually deploying your repo to https://clerk-beta-remix-vercel-p6l9qjlnm.clerkstage.dev/

[itsMapleLeaf]

It works! Love to see it 👏 Thanks y'all! Can finally remove that awful workaround I had 😂

[nikosdouvlis]

Great, glad to see this is resolved :) Thanks for reporting in the first place

[chribjel]

I am having issues with the redirect after sign-in/sign-up. I am always taken to /default-redirect

I have set redirects in the account portal, although the redirect_url query param is also set.

Is this a known issue?

[Hahlh]

With NextJS?

Did you specify the environment variables?

E.g.:

NEXT_PUBLIC_CLERK_SIGN_IN_URL="/sign-in"
NEXT_PUBLIC_CLERK_SIGN_UP_URL="/sign-up"

Reference: https://beta.clerk.com/docs/references/nextjs/custom-signup-signin-pages#update-your-environment-variables

Also, I think there might be a / missing in the beta docs for the path prop (Edit: PR here)

[chribjel]

Yes, i have tried setting env-variables, setting it in the account-portal, and setting it in the middleware like this

export default clerkMiddleware({
	afterSignInUrl: "/admin",
	afterSignUpUrl: "/admin",
});

[DennizSvens]

It appears that the types SignedInAuthObject and SignedOutAuthObject are no longer being exported. These types are referenced in the documentation for TRPCContext available here: https://clerk.com/docs/references/nextjs/trpc.

[desiprisg]

Hey @DennizSvens. Thanks for pointing this out. We'll be updating the docs for this. In the meantime, let me know if this works for you:

import * as trpc from '@trpc/server';
import * as trpcNext from '@trpc/server/adapters/next';
import { getAuth } from '@clerk/nextjs/server';
 
export const createContext = async (
  opts: trpcNext.CreateNextContextOptions
) => {
  return { auth: getAuth(opts.req) }
}

export type Context = trpc.inferAsyncReturnType<typeof createContext>;

[nikosdouvlis]

@DennizSvens, would you also please let us know if you have a need where the AuthObject (SignedInAuthObject | SignedOutAuthObject) type would be useful? Thank you

[camin-mccluskey]

I believe the use case for having this type would be to allow access to "internals" of the tRPC context (for testing/SSG Helpers). Can't say I've used this myself but perhaps others do.

[cenobitedk]

Here's another example where the types SignedInAuthObject and SignedOutAuthObject needs to be referenced.

  /**
   * Get auth session. Contains info about current organisation.
   *
   * @param request Express request object
   * @returns Auth object - SignedInAuthObject, SignedOutAuthObject or null
   */
  async getSession(request: Request): Promise<SignedInAuthObject | SignedOutAuthObject | null> {
    const requestState = await this.getRequestState(request);
    const auth = requestState.toAuth();
    return auth;
  }

[arolariu]

Hey,

The Clerk Core 2 Beta 41 so far seems very stable and performant. Great job team, you've done an awesome job on removing technical debt and improving performance overall! I'm very satisfied with Clerk. :)

One "dumb" question: I've looked at the beta docs and there's no documentation on how to chain multiple middlewares together. Only on how to add one middleware (see: https://beta.clerk.com/docs/references/nextjs/clerk-middleware#combining-middleware)

My problem is simple: I have a Content-Security Policy (CSP) middleware and an I18N middleware. I need them both to be online. How can I chain the middlewares?

Example code:

// file: middleware.ts

import {clerkMiddleware as authMiddleware, createRouteMatcher} from "@clerk/nextjs/server";

...

export default authMiddleware((auth, req) => {
  if (isProtectedRoute(req)) {
    auth().protect();
  }

  return cspMiddleware(req); 
  // ^--- here I'm using my csp middleware, but I want to use both this and my i18n middleware.
});

I'm using Next.JS btw.

[GiraffeCoding]

Hi,

I've added the middleware.ts file into the src folder as taken from the blog article:

// middleware.ts
import { clerkMiddleware, createRouteMatcher } from "@clerk/nextjs/server";

const isProtectedRoute = createRouteMatcher(["/dashboard(.*)"]);

export default clerkMiddleware((auth, request) => {
  if (isProtectedRoute(request)) auth().protect();
});

export const config = {
  matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
};

The auth seems to work as expected but I'm getting the following error in the console:

Any ideas as to why it's working but still giving this error.

note: This is a t3 app

[LekoArts]

We're happy to announce that Core 2 is now Generally Available (GA) 🎉
https://clerk.com/changelog/2024-04-19

Thanks for giving it a try - if you have any further feedback, feel free to leave it here or open an issue with a reproduction. Thanks!

[cenobitedk]

More or less same problem as @itsMapleLeaf posted recently, I get the same problem with a NestJS application.
I have created a repo with the bug here: https://github.com/cenobitedk/clerk5-nestjs-bug

error TypeError: Failed to parse URL from /protected
    at new Request (node:internal/deps/undici/undici:6110:19)
    at new ClerkRequest (/home/clerk5-nestjs-bug/node_modules/@clerk/backend/src/tokens/clerkRequest.ts:24:5)
    ... 6 lines matching cause stack trace ...
    at canActivateFn (/home/clerk5-nestjs-bug/node_modules/@nestjs/core/router/router-execution-context.js:135:59)
    at /home/clerk5-nestjs-bug/node_modules/@nestjs/core/router/router-execution-context.js:42:37 {
  [cause]: TypeError: Invalid URL
      at new URL (node:internal/url:796:36)
      at new Request (node:internal/deps/undici/undici:6108:25)
      at new ClerkRequest (/home/clerk5-nestjs-bug/node_modules/@clerk/backend/src/tokens/clerkRequest.ts:24:5)
      at createClerkRequest (/home/clerk5-nestjs-bug/node_modules/@clerk/backend/src/tokens/clerkRequest.ts:72:54)
      at authenticateRequest (/home/clerk5-nestjs-bug/node_modules/@clerk/backend/src/tokens/request.ts:66:57)
      at Object.authenticateRequest2 [as authenticateRequest] (/home/clerk5-nestjs-bug/node_modules/@clerk/backend/src/tokens/factory.ts:51:12)
      at AuthService.authenticateRequest (/home/clerk5-nestjs-bug/src/auth/auth.service.ts:26:32)
      at AuthGuard.canActivate (/home/clerk5-nestjs-bug/src/auth/auth.guard.ts:32:52)
      at GuardsConsumer.tryActivate (/home/clerk5-nestjs-bug/node_modules/@nestjs/core/guards/guards-consumer.js:15:34)
      at canActivateFn (/home/clerk5-nestjs-bug/node_modules/@nestjs/core/router/router-execution-context.js:135:59) {
    code: 'ERR_INVALID_URL',
    input: '/protected'
  }
}

The crash and reproduction is much the same, yet not with Remix or Vercel, but @itsMapleLeaf already posted some good thoughts on the problem.

NestJS runs on express and there's an additional problem with authenticateRequest(), see Other problems: https://github.com/cenobitedk/clerk5-nestjs-bug?tab=readme-ov-file#other-problems

@nikosdouvlis You fixed it last time, can you take a look at this as well?

[nikosdouvlis]

Hello @cenobitedk, many thanks for the report and the repo. I will take a look and update the thread here with more details :)

[cenobitedk]

Hi @nikosdouvlis
Any updates on this?

[cenobitedk]

Hi @nikosdouvlis Would love of you had time to investigate this 🙂🙏

[patryk-reba]

Hi, I am getting this error, even though I am using catch-all route. Do you have some idea why it happens?

[colinclerk]

Thanks for the report. Can you check if it resolves if you remove the (auth) route group?

(We'll treat as a bug if that's the case, just trying to narrow it down!)

[patryk-reba]

Still the same :( Might it be the case that it's because of local environment?
Even though there is an error, everything is working fine:

Setup:

[patryk-reba]

[bwilytsch]

Did you have a chance to look into this, @colinclerk. Thanks 🙏