Replies: 1 comment
-
I'm open to the idea, would be good to look at the work required to integrate it and double check that all our tests still pass (and then potentially remove our parse tests). also might want @ncb000gt to weigh in because this would be a fundamental change to the project |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've been thinking about this for a while now: we might be better off delegating the expression parsing to
harrisiirak/cron-parser
and focusing on handling the scheduling part.cron-parser
's current unpacked size is 122 kB and uses Luxon just like we do to provide DateTime/timezone/offset support.The maintainer has done a great job with this library, and it handles all the
cron
syntaxes we don't (namelyL
,#
, and?
). Although?
is just an alias for*
instead of being substituted with the initialization time like in nnCron, we might propose a PR to add a flag to switch behaviors.The repository also has benchmarks, so it would be interesting to run them against our
CronTime._parse()
function to compare.Overall this just looks like a win for everyone: supporting more features, improving ecosystem compatibility, combining maintenance efforts, and probably improving
cron
's performance at the same time.Would love your thoughts on this @intcreator @harrisiirak!
Beta Was this translation helpful? Give feedback.
All reactions