Preliminary Checks
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:
- install
@clerk/clerk-sdk-node@4.12.23
- Add code that calls
clerkClient.verifyToken(token)
- Watch as typescript throws a fit because it's expecting 2 arguments. Weird.
- 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
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:
@clerk/clerk-sdk-node@4.12.23clerkClient.verifyToken(token)issuerto 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 (
ExtendedClerktype references@clerk/backendfor theverifyTokentype)[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
issuerhasn't been made optional in the option signature, even though it is optional in the code forverifyToken.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:
verifyTokensignature won't allow singletokenargument without breaking.Environment
Doesn't matter