-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement iterable/valueOf for decoupling from libraries #203
base: master
Are you sure you want to change the base?
Conversation
A dependent library could use this knowing only that `expression: Iterable<{ valueOf(): number }>` (where multiple date libraries support valueOf() already (including JS Date and luxon DateTime).
An example I'm thinking of is a fork of node-scheduler that just implements one-off or iterable dates, so it doesn't need to bundle any specific cron-parser (and therefore date library), instead the user chooses this cron-parser and uses it like:
i.e. I definitely want to avoid the moment-timezone bundle size/EOL but although my preference for change is Luxon, if instead DayJs is used, I can maintain a Luxon fork to avoid needing to bundle two date libraries in my project (and avoid DayJs timezone data). |
tbh, not having this isn't really a blocker to my idea. I'd just need an adapter to map the expression to the format my hypothetical node-scheduler fork would support without making it a hard dependency. The valueOf functionality would still be useful though as is standard in JS Date/some other date libraries |
@harrisiirak Any update on merging this PR? Not being able to use |
|
||
var iterated = [...interval].map((date) => date.toJSON()); | ||
var expected = [ | ||
"2012-12-26T14:40:00.000Z", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer single quotes over double quotes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep fair enough. I'm just used to eslint formatting on save :)
master has gone quite in a bit of a different direction since, at least with the CronExpression type, so may be tricky to sort out |
i.e I don't know how to integrate:
with
so if you knew and could sort it out, that's fine. |
@andytson can't we just do: export interface ICronExpression<CronFields, IsIterable extends boolean> extends Iterable<CronDate> { Tested it locally and it seems to be working fine in this way. |
A dependent library could use this knowing only that
expression: Iterable<{ valueOf(): number }>
(where multiple date libraries support valueOf() already (including JS Date and luxon DateTime).Fixes #82