CronRepeatOptions.repeat is wrongly enforcing declaration of the 'key' property in TS
reinert opened this issue · comments
Description
The 4.11 release, specifically the (e4e6457) commit, introduced a requirement in the repeat
property of the CronRepeatOptions
TS type to set a readonly key
property. This is requiring us to declare the key property to add scheduled jobs. For example, if we try to add a job with the opts { repeat: { cron: "* * * * *" } }
the TS compiler will fail with the following message:
error TS2322: Type '{ cron: string; }' is not assignable to type '((CronRepeatOptions | EveryRepeatOptions) & { readonly key: string; }) | undefined'.
Type '{ cron: string; }' is not assignable to type 'CronRepeatOptions & { readonly key: string; }'.
Property 'key' is missing in type '{ cron: string; }' but required in type '{ readonly key: string; }'.
According to the documentation this property is not set by the user, but by Bull. So this type declaration should be modified to conform with the documentation.
Minimal, Working Test code to reproduce the issue.
Try sending a scheduled job without the key property in TS and the compilation error will appear.
Bull version
4.11
Additional information
Introduced by this commit:
types: add missing keys to repeat opts (e4e6457)
From what I gather, the key
is simply generated here:
Line 41 in dab0d82
Before it's set on the scheduled job:
Line 65 in dab0d82
So my guess is that the type is correct as a return value, but not for input 🤷 At least, tracing the opts
from scheduling a job with repeatable configuration leads me to the lines above, where the key
isn't ever actually used.
Got the same issue. Is a fix expected soon?
Running into the same issue
Let me know if the fix solves the issue.
🎉 This issue has been resolved in version 4.11.3 🎉
The release is available on:
Your semantic-release bot 📦🚀