First of all, this library is amazing at so many things. Thank you for offering such a feature-rich module. However, for my project it actually has too many features.
I want to use this to offer some QoL features on a frontend website (such as the next 5 times the cronjob would fire, to provide visual feedback when entering a cron expression). This website interacts with a backend system running jobs according to the cron schedules and does not support any cron extensions, so expressions such as "@weekly" or " 2L " or anything with the seconds field will fail validation.
This is not the end of the world, as I can easily catch this and show it back to the user as an error. However, ideally the frontend would catch these edge cases as well, both to prevent a network round-trip and to not appear to accept an input on the frontend only for the backend to reject it.
Could the options dictionary be extended to add a disableExtensions option, in which the parser would only conform to the original cron spec?
First of all, this library is amazing at so many things. Thank you for offering such a feature-rich module. However, for my project it actually has too many features.
I want to use this to offer some QoL features on a frontend website (such as the next 5 times the cronjob would fire, to provide visual feedback when entering a cron expression). This website interacts with a backend system running jobs according to the cron schedules and does not support any cron extensions, so expressions such as "@weekly" or " 2L " or anything with the seconds field will fail validation.
This is not the end of the world, as I can easily catch this and show it back to the user as an error. However, ideally the frontend would catch these edge cases as well, both to prevent a network round-trip and to not appear to accept an input on the frontend only for the backend to reject it.
Could the
options
dictionary be extended to add adisableExtensions
option, in which the parser would only conform to the original cron spec?Many thanks!