Fix: exp type & overriding default exp value

[damnmicrowave]

Technically, jose supports passing timey strings, e.g. '1h', '10days' etc. (here)
This PR updates the type of exp to be string as well as a number for that.

Also, this fixes overriding exp value when calling jwt.sign() method.
Example:

const token = await jwt.sign({
  userId: 'qwbfo21b9d',
  exp: '1h', // <~ this now works fine. Previously this was ignored and threw a type error
})

[fallow64]

I was so confused why my exp field was not being passed into my token; this would be a great QOL feature, and certainly would save others from hours of debugging.

[pichxyaponn]

Hi @damnmicrowave,

Thanks a lot for opening this PR and pointing out the issue regarding dynamic exp configuration in jwt.sign(). I completely agree with both you and @fallow64 that this has been a point of confusion, and resolving it would indeed be a significant quality-of-life improvement for usability.

I've forked this library and have been working on some enhancements, including a fix for this particular issue, in my version. I wanted to share it in case it might be helpful.

In my version (@pichxyaponn/elysia-jwt), the jwt.sign() method now correctly processes exp and nbf values passed directly in the payload, allowing dynamic overrides of exp and nft. Additionally, I've updated the jwt.verify() method has been refactored to throw errors when it is token expired, instead of returning false, which allows for more granular error handling.

Given that the main repository may not have been updated for a while, my fork could serve as an alternative for anyone looking for these features or facing the same issues. I'm also open to feedback and further suggestions on my version.

If you're interested, you can find more details here: