Introduction

There is no daemon to install and no broker to run. The package has no dependencies and works on Bun and Node.

import Baker from "cronbake";

const baker = Baker.create();

baker.add({
  name: "clear-expired-sessions",
  cron: "@every_15_minutes",
  callback: async () => {
    await clearExpiredSessions();
  },
});

baker.bakeAll();

What it does

• Schedules down to the second. Six-field cron expressions, plus presets such as @daily and @at_18:30 that TypeScript can check for you.
• Job control by name. Start, stop, pause, resume or remove one job, or all of them at once.
• Overlap protection. If a run is still going when the next one is due, the next one is skipped and counted.
• A record of each job. Totals, average duration, the last error and a capped history of recent runs.
• Optional persistence. Save job definitions to a file, to Redis or to your own store.
• Your logger. Pass anything with info, warn, error and debug methods.

Two classes

Baker keeps a set of named jobs and is what most apps need. You add jobs to it, start them, and ask it about them by name.

Cron is a single job. Baker creates these for you, and you can also use one on its own. Its static methods work without a job at all, so Cron.isValid() and Cron.getNext() are handy for validating user input or showing the next run time in a UI.

When to use something else

Cronbake runs in one process and doesn’t coordinate with anything. That keeps it small, and it also sets some limits.

• Several instances of your app. Each instance runs every job, because there is no distributed lock. Running in production covers the usual ways around this.
• Serverless functions. Nothing keeps a process alive between requests, so timers don’t fire. Use your platform’s scheduler.
• Work that must happen. Missed ticks aren’t replayed and failed runs aren’t retried. If a job has to complete eventually, a queue such as BullMQ is the better tool.
• Per-job time zones. Every schedule follows the time zone of the process.