I wasn't aware that node clamps its timeouts to values that fit in 32-bit unsigned integer (so, ~2.1b milliseconds). That corresponds to ~24.8 days.

I tried setting up a ttl of 30 days (~2.6b milliseconds), and tripped over this warning:

(node:562983) TimeoutOverflowWarning: 2592000000 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
    at new Timeout (node:internal/timers:189:17)
    at setTimeout (node:timers:120:19)
    at TTLCache.setTimer (file:///.../node_modules/@isaacs/ttlcache/dist/esm/index.js:65:19)
    at TTLCache.setTTL (file:///.../node_modules/@isaacs/ttlcache/dist/esm/index.js:129:22)
    at TTLCache.set (file:///.../node_modules/@isaacs/ttlcache/dist/esm/index.js:157:18)

At a minimum here, I think maybe TTLCache should document the maximum allowed value in the README, and catch when you pass too big of a value, and throw an exception or something, so that you're not just getting more cryptic warnings from node -- by default you don't get the stack trace, just the top-line warning which mentions nothing about TTLCache.

Alternatively, it seems like maybe TTLCache could, in the case of longer ttl's than the allowed max timer, de-couple the ttl length from timer value -- maybe cap timer at a max of 1 day? 7 days? 24 days?)

Moreover, my online research seems to indicate that the typical work-around for setting longer timers is to stack timers, so maybe TTLCache could just compute how many stacked timers it needs to do to respect the specified ttl?

I'm happy to PR any/either of these 3 strategies, if you provide any feedback on how you think this might be best addressed?