Node SDK: verifyToken function has wrong signature #2280

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs

• I have searched for existing issues: https://github.com/clerk/javascript/issues

• I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

• This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction / Replay Link

https://github.com/clerk/javascript/blob/main/packages/sdk-node/src/clerkClient.ts#L11

Publishable key

yeah, nah

Description

Steps to reproduce:

1. install @clerk/clerk-sdk-node@4.12.23
2. Add code that calls clerkClient.verifyToken(token)
3. Watch as typescript throws a fit because it's expecting 2 arguments. Weird.
4. Add options object as second parameter. Watch typescript throw a tantrum asking for the issuer to be specified even though it shouldn't be required.

Expected behavior:

The signature should be able to accept a single argument as per your code, but because the (ExtendedClerk type references @clerk/backend for the verifyToken type)[https://github.com/clerk/javascript/blob/main/packages/sdk-node/src/clerkClient.ts#L11] and since that signature is a broken, it breaks the child.

I personally find it weird that the backend code requires the second argument with empty object fallback as all the properties inside this options object should be optional except for some reason, the issuer hasn't been made optional in the option signature, even though it is optional in the code for verifyToken.

Furthermore, code like this type signature makes it extremely hard to read and gives very little value to your developers other than not having to copy some types over, but the issue now lies that the base type has immense power over your SDK signature which can break things as clearly shown here. Having 2 picks and your own extension to the type shows that your types are not well thought out and should be reassessed for better abstraction, or maybe it might be easier to just have an explicit type for each function to prevent these kinds spaghetti type issues in the future.

Actual behavior:

verifyToken signature won't allow single token argument without breaking.

Environment

Doesn't matter