I've elected to change the interface here and split it into two functions rather than re-use the same one. That way, the cached one doesn't need to return a promise. This does make it a BREAKING CHANGE. I've given both functions different names so it's obvious that they're different. It's a trivial code update so I don't really think its worth having a backwards compat function?
It also splits some code out of client.ts(!)
Any of the tests that use runAllTimers() needed replacing with something that would just run the ones they need, since this works by continually setting a timer to keep the capabilities up to date. I don't think runAllTimers() is a sensible thing to use unless you're testing a small piece of code where you know all the timers it's setting.
Checklist
[ ] Tests written for new code (and old code if feasible).
[ ] New or updated public/exported symbols have accurate TSDoc documentation.
Perhaps, but I don't think it would be useful to us right now, particularly? Especially given it will only update every 6 hours, normally. I'd be inclined to keep any extra complexity out until its needed.
& keep them up to date.
I've elected to change the interface here and split it into two functions rather than re-use the same one. That way, the cached one doesn't need to return a promise. This does make it a BREAKING CHANGE. I've given both functions different names so it's obvious that they're different. It's a trivial code update so I don't really think its worth having a backwards compat function?
It also splits some code out of client.ts(!)
Any of the tests that use
runAllTimers()
needed replacing with something that would just run the ones they need, since this works by continually setting a timer to keep the capabilities up to date. I don't thinkrunAllTimers()
is a sensible thing to use unless you're testing a small piece of code where you know all the timers it's setting.Checklist
public
/exported
symbols have accurate TSDoc documentation.