cron vs node-schedule vs agenda vs bree vs bull vs later vs node-cron
Node.js におけるタスクスケジューリングとジョブキューのアーキテクチャ選定
パッケージを検索...
cronnode-scheduleagendabreebulllaternode-cron類似パッケージ:

Node.js におけるタスクスケジューリングとジョブキューのアーキテクチャ選定

agenda、bree、bull、cron、later、node-cron、node-schedule は、Node.js アプリケーション内で時間ベースのタスク実行やバックグラウンドジョブ処理を実現するためのライブラリ群です。これらは大きく分けて 2 つのカテゴリに分類されます。一つは、Cron 構文や自然言語に基づいて特定の日時にコードを実行する「スケジューラ」（node-cron、node-schedule、cron、later）であり、もう一つは、Redis や MongoDB などの外部ストレージを利用してジョブの永続化、再試行、優先度管理を行う「ジョブキュー」（bull、agenda、bree）です。フロントエンドアーキテクチャの観点からは、サーバーサイドレンダリング（SSR）中のデータ取得、定期的なキャッシュ更新、あるいは長時間実行される重い処理の非同期オフロードといったシナリオにおいて、適切なツールを選定することがシステムの信頼性と拡張性に直結します。

npmのダウンロードトレンド

3 年

GitHub Starsランキング

統計詳細

パッケージ
ダウンロード数
Stars
サイズ
Issues
公開日時
ライセンス
cron3,919,3978,952161 kB3910ヶ月前MIT
node-schedule1,953,3319,19835 kB1734年前MIT
agenda82,6969,709301 kB443ヶ月前MIT
bree03,29692 kB298ヶ月前MIT
bull016,254309 kB1482年前MIT
later02,407-9811年前MIT
node-cron03,282328 kB93ヶ月前ISC

Node.js タスクスケジューリングとジョブキューの完全比較：アーキテクチャ選定の指針

Node.js アプリケーションにおいて、時間の経過とともにタスクを実行する必要性は頻繁に発生します。例えば、毎日のレポート生成、キャッシュの更新、あるいはユーザーへのメール送信などです。ここで紹介する 7 つのパッケージ（agenda, bree, bull, cron, later, node-cron, node-schedule）は、この課題を解決するための代表的なツールですが、そのアプローチは大きく 2 つに分かれます。

一つは「スケジューラ」であり、特定の時刻になったらコードを実行するものです。もう一つは「ジョブキュー」であり、タスクをキューに詰め込み、ワーカーが順番に処理していくものです。どちらを選ぶかは、データの永続性が必要か、処理の規模はどれくらいか、そしてインフラに何を導入できるかによって決まります。

🏗️ アーキテクチャの根本的な違い：ステートレス vs 永続化

まず理解すべきは、これらのツールが「状態（State）」をどこで管理しているかという点です。

スケジューラ系（node-cron, node-schedule, cron, later）は、基本的にメモリ上で動作します。プロセスが再起動すると、設定したスケジュールは消滅します。これらは「その瞬間」を実行することに特化しており、ジョブの履歴や失敗時の再試行ロジックは自分で実装する必要があります。

ジョブキュー系（bull, agenda, bree）は、外部ストレージ（Redis, MongoDB, ファイルシステム）にジョブの状態を保存します。プロセスが落ちてもジョブは消えず、再起動後に再開できます。また、複数のサーバーで同じキューを共有することで、負荷分散も可能です。

⏰ スケジューラの実装比較：Cron 構文と柔軟性

定期実行タスクを実装する際、構文の書きやすさと機能性が重要です。ここでは、node-cron、node-schedule、および非推奨の cron、later を比較します。

1. 基本的な Cron 構文の実装

node-cron は、標準的な Cron 構文をサポートし、API がシンプルで現代的なプロジェクトでよく使われます。

const cron = require('node-cron');

// 毎分実行
const task = cron.schedule('* * * * *', () => {
  console.log('毎分実行されます');
});

// 一時停止や再開も容易
task.stop();
task.start();

cron パッケージも同様の構文を使いますが、メンテナンス状況が不安定なため、新規採用は推奨されません。API は似ていますが、生態系のサポートが薄れています。

const CronJob = require('cron').CronJob;

// 毎分実行
const job = new CronJob('* * * * *', function() {
  console.log('毎分実行されます');
});
job.start();

node-schedule は、Cron 構文に加え、より人間に優しいルールや Date オブジェクトを直接指定できる柔軟性があります。

const schedule = require('node-schedule');

// Cron 構文での指定
const job1 = schedule.scheduleJob('* * * * *', function() {
  console.log('毎分実行されます');
});

// 自然言語的なルール（毎週月曜日の 12:30）
const job2 = schedule.scheduleJob('DayOfWeek Hour:Minute', function() {
  console.log('月曜日の 12:30 に実行');
});

// 特定の時刻（Date オブジェクト）に 1 回だけ実行
const date = new Date(Date.now() + 5000);
const job3 = schedule.scheduleJob(date, function() {
  console.log('5 秒後に 1 回実行');
});

2. 複雑なスケジュールと非推奨パッケージ

later は、非常に複雑なスケジュール（例：「月の最初の平日の午前 9 時」など）を記述できる強力な構文を持っていましたが、現在はメンテナンスされていません。新規プロジェクトで使用すべきではありません。

// later の例（非推奨のため参考のみ）
const later = require('later');

const schedule = later.parse.text('every weekday at 9:00 am');
later.setInterval(() => {
  console.log('複雑なスケジュール実行');
}, schedule);

選定のポイント: シンプルな定期実行なら node-cron が十分です。もし「特定の日のみ」や「動的な日付」を扱う必要があるなら、node-schedule の方が直感的でバグを埋め込みにくくなります。cron や later は、既存レガシーコードの維持以外では選択しないようにしましょう。

🚀 ジョブキューの実装比較：信頼性と拡張性

バックグラウンドで重い処理（画像リサイズ、メール送信、外部 API 連携など）を行う場合、ジョブキューが必須です。ここでは bull、agenda、bree を比較します。

1. Redis を活用した高速処理：bull

bull は Redis をバックエンドに使用し、非常に高速で信頼性が高いのが特徴です。ジョブの優先度、再試行、進行状況の報告など、エンタープライズ級の機能が揃っています。

const Queue = require('bull');

// キューの作成（Redis 接続が必要）
const imageQueue = new Queue('image processing', 'redis://127.0.0.1:6379');

// ジョブの追加
imageQueue.add({ imageUrl: 'https://example.com/img.png' }, {
  attempts: 3, // 失敗時 3 回再試行
  backoff: { type: 'exponential', delay: 1000 }
});

// ワーカーの実装
imageQueue.process(async (job) => {
  console.log(`処理中: ${job.data.imageUrl}`);
  // 画像リサイズ処理など
  job.progress(50); // 進捗報告
  return { success: true };
});

2. MongoDB を活用した柔軟な定義：agenda

agenda は MongoDB を使用します。ジョブの定義をデータベースに保存できるため、アプリケーションコードを変更せずに DB 上でジョブを管理できる利点があります。

const Agenda = require('agenda');
const agenda = new Agenda({ db: { address: 'mongodb://localhost/agenda' } });

// ジョブの定義
agenda.define('send email', async (job) => {
  const { to, subject } = job.attrs.data;
  console.log(`${to} に ${subject} を送信`);
});

// ジョブのスケジューリング
await agenda.start();
await agenda.every('10 minutes', 'send email', { to: '[email protected]', subject: '定期メール' });

// 一度きりのジョブ
await agenda.schedule('in 20 minutes', 'send email', { to: '[email protected]', subject: '警告' });

3. ファイルベースの軽量構成：bree

bree は、Redis や MongoDB を必要とせず、ファイルシステム上でジョブを管理します。ワーカーを別プロセスとして起動するため、メモリリークの影響を受けにくい設計になっています。

const Bree = require('bree');
const path = require('path');

const bree = new Bree({
  root: path.join(__dirname, 'jobs'), // ジョブスクリプトが入ったフォルダ
  jobs: [
    { name: 'daily-report', interval: 'at 12:00 am' },
    { name: 'process-images', path: path.join(__dirname, 'workers', 'image-worker.js') }
  ]
});

bree.start();

// ジョブスクリプト (jobs/daily-report.js)
// module.exports = async () => { console.log('レポート生成'); };

選定のポイント: Redis を導入できる環境で、高いパフォーマンスと機能性を求めるなら bull がベストです。既に MongoDB を使っており、ジョブ定義を DB で管理したい場合は agenda が適しています。インフラを増やしたくない、あるいはワーカーのプロセス分離を簡単に実現したい場合は bree が優れた選択肢です。

⚠️ エラーハンドリングと永続性の挙動

ジョブが失敗した時の挙動も重要な選定基準です。

  • bull: 組み込みの再試行機能が強力です。attempts オプションで再試行回数を指定でき、バックオフ戦略（再試行までの待機時間を徐々に増やすなど）も設定可能です。ジョブは Redis に残るため、サーバーが落ちても復旧後に再開されます。
  • agenda: MongoDB にジョブ状態が保存されるため、プロセス停止後もジョブは失われません。ただし、ロック機構を使用しているため、長時間実行されるジョブがデッドロックを起こさないよう注意が必要です。
  • bree: ワーカープロセスがクラッシュしても、メインプロセスがそれを検知し、必要に応じて再起動できます。設定により、失敗したジョブの再試行も可能です。
  • スケジューラ系 (node-cron など): 基本的にエラーハンドリングはユーザー任せです。try-catch で囲まないとプロセスが終了する可能性があり、再試行ロジックも自分で実装する必要があります。また、プロセス再起動でスケジュールがリセットされるため、重要なタスクには不向きです。

📊 実装コードでの比較まとめ

各パッケージがどのように「10 分後に実行」というタスクを扱うかを見てみましょう。

// node-schedule (スケジューラ)
const date = new Date(Date.now() + 10 * 60 * 1000);
schedule.scheduleJob(date, () => console.log('10 分後'));

// node-cron (スケジューラ - 厳密な 10 分後は難しいため近似)
// 毎分チェックして条件分岐するか、setTimeout を併用する必要がある
setTimeout(() => console.log('10 分後'), 10 * 60 * 1000);

// bull (キュー - 遅延実行)
queue.add({ type: 'task' }, { delay: 10 * 60 * 1000 });

// agenda (キュー/スケジューラハイブリッド)
agenda.schedule('in 10 minutes', 'myTask');

// bree (スケジューラ設定)
// jobs 配列で interval: 'in 10 minutes' と指定

💡 最終的なアーキテクチャの指針

フロントエンドアーキテクチャの文脈では、サーバーサイドレンダリング（SSR）中のデータ取得にこれらのツールを使うことは稀ですが、SSR のキャッシュ戦略や、ユーザーアクションに対する非同期フィードバック（例：「エクスポート準備ができたらメールします」）において重要な役割を果たします。

  • シンプルさ最優先: インフラを増やしたくない小規模プロジェクトなら、node-cron または bree がおすすめです。特に bree はプロセス分離のメリットが大きく、安定性が高いです。
  • 信頼性と機能性: 重要なビジネスロジックや、大量のジョブを処理する必要がある場合は、Redis を導入してでも bull を選ぶべきです。その機能性は開発中の悩みを大きく減らしてくれます。
  • MongoDB エコシステム: 既に MongoDB を使っていて、ジョブの可視性や動的な管理を重視するなら agenda が自然な選択です。
  • 避けるべき選択: cron と later はメンテナンスの観点から、新規プロジェクトでは使用を避けてください。node-cron や node-schedule で十分な代替が可能です。

どのツールを選ぶにしても、「プロセスが落ちたらジョブはどうなるか？」という問いに答えられる構成にすることが、プロフェッショナルなシステム設計の第一歩です。

選び方: cron vs node-schedule vs agenda vs bree vs bull vs later vs node-cron

  • cron:

    純粋な Cron 構文のパーサーとして機能し、特定の時刻にコールバックを実行するだけのシンプルな用途に限定して使用します。ジョブの永続化や管理機能は含まれていないため、プロセスが再起動するとスケジュールがリセットされる点に注意が必要です。現代的なプロジェクトでは、よりメンテナンスが活発で機能豊富な node-cron や node-schedule の使用を検討すべきであり、新規プロジェクトでの採用は推奨されません。

  • node-schedule:

    Cron 構文だけでなく、特定の Date オブジェクトや自然言語的なルール（例：『毎週月曜日の午前 9 時』）でスケジュールを定義したい場合に node-schedule を選択します。可読性の高いスケジュール定義が可能で、ジョブのキャンセルや再スケジュールも容易です。データベースを必要としない範囲で、柔軟かつ直感的な時刻指定が必要なアプリケーションに適しています。

  • agenda:

    MongoDB を既にインフラとして利用しており、ジョブの定義をコード内ではなくデータベース上で動的に管理したい場合に agenda を選択します。ジョブの実行履歴や状態を DB で永続化できるため、プロセスが再起動してもジョブが失われません。ただし、MongoDB への依存と、ロック機構によるパフォーマンスの限界があるため、超高速な処理や Redis 環境では他の選択肢を検討すべきです。

  • bree:

    ファイルシステムに基づいてジョブを管理し、外部データベース（Redis や MongoDB）を一切必要としない軽量な構成を求める場合に bree が最適です。ワーカープロセスを分離して実行するため、メモリのリークがメインプロセスに影響しにくい利点があります。小規模から中規模のプロジェクトで、インフラの複雑さを増やさずに堅牢なバックグラウンド処理を実装したい時に推奨されます。

  • bull:

    Redis を利用可能で、高いスループット、ジョブの優先度制御、詳細なイベント処理、そして分散環境での信頼性を求める場合には bull が事実上の標準です。ジョブの進行状況の監視や失敗時の再試行戦略を細かく制御できるため、大規模なバックグラウンド処理システムに適しています。Redis のメンテナンスコストを受け入れられるなら、最も機能豊富で信頼性の高い選択肢です。

  • later:

    自然言語に近い形式や複雑なスケジュール構文で時刻を定義する必要がある場合に使用しますが、このパッケージは現在メンテナンスが終了しており、新規プロジェクトでの使用は避けるべきです。機能面では柔軟性がありますが、セキュリティアップデートやバグ修正が見込めないため、代替として node-schedule や croner などの維持されているライブラリへの移行を強く推奨します。

  • node-cron:

    外部依存なしで Cron 構文に基づいてタスクをスケジュールしたい場合の、バランスの取れた選択肢です。cron パッケージよりもメンテナンスが活発で、Node.js の最新の機能にも対応しています。ジョブの永続化機能はありませんが、シンプルな定期実行タスク（例：毎日のバッチ処理）をステートレスに実行したい場合に適しており、導入コストが低いのが特徴です。

cronと類似したnpmパッケージ

cron は、Node.js アプリケーションでのスケジュールされたタスクの実行を簡単に管理するためのライブラリです。UNIX の cron ジョブに触発されたこのパッケージは、特定の時間や間隔で関数を実行するためのシンプルで強力なインターフェースを提供します。cron は、定期的なタスクを自動化したい開発者にとって非常に便利です。しかし、cron には他にもいくつかの代替ライブラリがあります。以下にいくつかの選択肢を紹介します。

  • agenda は、MongoDB をバックエンドに持つスケジューラーです。ジョブをデータベースに保存し、指定した時間に実行することができます。agenda は、特に大規模なアプリケーションや複雑なスケジュールが必要な場合に便利です。スケジュールされたタスクの管理が容易で、再試行や遅延の設定も可能です。
  • later は、柔軟なスケジューリングを提供するライブラリで、複雑なスケジュールを簡単に定義できます。cron 式を使用する代わりに、より直感的なオブジェクト形式でスケジュールを設定できるため、特に複雑なスケジュールを必要とする場合に役立ちます。later は、特定の時間、日、または週の特定のパターンでタスクを実行する必要がある場合に最適です。
  • node-cron は、Node.js 環境で cron ジョブを簡単に作成できるライブラリです。cron 式を使用してスケジュールを設定し、指定した時間に関数を実行することができます。node-cron は、シンプルで使いやすく、軽量なため、簡単なスケジューリングが必要なプロジェクトに最適です。

これらのパッケージの比較については、こちらをご覧ください: agenda vs cron vs later vs node-cron。

node-scheduleと類似したnpmパッケージ

node-scheduleは、Node.jsアプリケーションでスケジュールされたタスクを実行するためのライブラリです。このライブラリは、特定の時間や間隔でジョブをスケジュールし、実行することを可能にします。node-scheduleは、柔軟性と使いやすさを兼ね備えたスケジューリングソリューションを提供しますが、他にもいくつかの代替ライブラリがあります。以下にいくつかの選択肢を紹介します。

  • agendaは、MongoDBをバックエンドに持つジョブスケジューラーです。非同期のタスクを簡単にスケジュールし、管理することができます。agendaは、特にデータベースに依存したタスク管理が必要な場合に便利です。タスクの再試行や優先順位付けなどの高度な機能を提供し、複雑なジョブスケジューリングに対応します。
  • cronは、Unix系のcronの機能をNode.jsに持ち込んだライブラリです。cronは、特定の時間や日付に基づいてタスクをスケジュールするための非常に強力なツールです。cronの表現を使用して、複雑なスケジュールを簡単に設定できるため、定期的に実行する必要があるタスクに最適です。
  • laterは、柔軟なスケジューリングを提供するライブラリで、時間の表現を簡単に設定できます。laterは、様々なスケジュールのパターンをサポートしており、複雑なスケジュールを簡単に作成することができます。特に、時間の範囲や繰り返しのパターンを設定する際に便利です。
  • node-cronは、Node.jsでcronの機能を実装したライブラリです。シンプルなAPIを提供し、cron式を使用してタスクをスケジュールすることができます。node-cronは、軽量で使いやすく、特に簡単なスケジューリングが必要な場合に適しています。

これらのライブラリの比較については、こちらをご覧ください: agenda vs cron vs later vs node-cron vs node-scheduleの比較。

agendaと類似したnpmパッケージ

agenda は、Node.js アプリケーションのためのジョブスケジューリングライブラリです。MongoDB をバックエンドとして使用し、簡単にジョブをスケジュール、管理、実行することができます。Agenda は、定期的なタスクや遅延実行が必要なタスクを扱うのに非常に便利です。しかし、Agenda には他にも多くの選択肢があります。以下はそのいくつかの代替ライブラリです。

  • bull は、Redis をバックエンドに使用した高性能なジョブおよびメッセージキューライブラリです。Bull は、バックグラウンドでのタスク処理、再試行、優先順位付け、遅延キューなど、非常に多機能です。特に、スケーラブルなアプリケーションや高負荷の環境での使用に適しています。Bull は、ジョブの状態管理や進捗状況のトラッキングが容易で、強力なエコシステムを持っています。
  • node-schedule は、Node.js 環境でのスケジュールされたタスクを管理するためのシンプルなライブラリです。Cron スタイルのスケジューリングをサポートしており、特定の時間や間隔でタスクを実行することができます。node-schedule は、軽量で使いやすく、簡単なスケジューリングが必要な場合に最適です。

これらのライブラリの比較については、以下のリンクを参照してください: Comparing agenda vs bull vs node-schedule。

breeと類似したnpmパッケージ

bree は、Node.js アプリケーション向けのジョブスケジューリングライブラリです。シンプルで使いやすく、バックグラウンドでのタスク実行を効率的に管理することができます。Bree は、特に軽量でありながら強力な機能を提供しており、定期的なタスクや遅延タスクを簡単にスケジュールできます。Bree のユニークな点は、ワーカーを使用してジョブを実行するため、スケーラビリティが高く、パフォーマンスも優れています。しかし、Bree 以外にも多くのジョブスケジューリングライブラリが存在します。以下は、そのいくつかの代替品です。

  • agenda は、MongoDB をバックエンドに持つジョブスケジューリングライブラリです。非同期タスクを簡単にスケジュールでき、タスクの状態をデータベースに保存することができます。Agenda は、特にデータベースを使用したタスク管理が必要なアプリケーションに適しています。
  • bull は、Redis を使用した高性能なジョブスケジューラーです。バックグラウンドでのタスク処理に最適で、優れたパフォーマンスとスケーラビリティを提供します。Bull は、タスクの再試行や優先順位付けなどの機能を備えており、複雑なタスク管理が可能です。
  • cron は、Unix の cron ジョブにインスパイアされたシンプルなジョブスケジューリングライブラリです。特定の時間や間隔でタスクを実行するための柔軟な構文を提供します。Cron は、定期的なタスクを簡単にスケジュールしたい場合に適しています。
  • later は、ジョブスケジューリングのための柔軟なライブラリで、複雑なスケジュールを簡単に設定できます。特に、特定の時間や日付に基づくスケジュールを設定するのに便利です。
  • node-cron は、Node.js 用の cron タイマーライブラリで、シンプルな API を提供します。簡単に定期的なタスクをスケジュールでき、使いやすさが特徴です。
  • node-schedule は、Node.js 用のスケジューリングライブラリで、特定の日時にタスクを実行するための機能を提供します。柔軟なスケジュール設定が可能で、特定の日時に基づくタスクを簡単に管理できます。

これらのライブラリの比較については、以下のリンクを参照してください: Comparing agenda vs bree vs bull vs cron vs later vs node-cron vs node-schedule.

bullと類似したnpmパッケージ

bullは、Node.jsアプリケーション向けの高性能なジョブおよびメッセージキューライブラリです。Redisをバックエンドとして使用し、ジョブの管理、スケジューリング、再試行、優先順位の設定など、さまざまな機能を提供します。bullは、特に高負荷のアプリケーションやバックグラウンド処理が必要なシステムに適しています。しかし、bullにはいくつかの代替ライブラリもあります。以下にいくつかの選択肢を紹介します。

  • agendaは、MongoDBをバックエンドに使用するジョブスケジューラです。シンプルなAPIを提供し、定期的なジョブのスケジューリングや、特定の条件に基づくジョブの実行を容易にします。MongoDBを使用しているプロジェクトに適しており、シンプルなタスクスケジューリングが必要な場合に便利です。
  • bee-queueは、シンプルで高速なジョブキューライブラリで、Redisをバックエンドに使用しています。特に低レイテンシーのジョブ処理を重視しており、簡単に使用できるAPIを提供します。軽量なジョブキューが必要な場合や、シンプルなタスク処理を行いたい場合に適しています。
  • bullmqは、bullの次世代版として設計されたジョブおよびメッセージキューライブラリです。bullの機能を引き継ぎつつ、より高いパフォーマンスと新しい機能を提供します。特に、複雑なジョブフローや大規模なアプリケーションに対応するために最適化されています。
  • kueは、Node.js用の優れたジョブおよびメッセージキューライブラリで、Redisをバックエンドに使用しています。ジョブの優先順位付けや進行状況の追跡、再試行などの機能を提供し、視覚的なダッシュボードも備えています。複雑なジョブ管理が必要な場合に適しています。
  • node-resqueは、Redisを使用したジョブキューライブラリで、バックグラウンドジョブの処理を簡素化します。シンプルなAPIと、複数のバックエンドに対応した柔軟性を持ち、さまざまなアプリケーションに適応可能です。

これらのライブラリの比較については、以下のリンクを参照してください: agenda vs bee-queue vs bull vs bullmq vs kue vs node-resqueの比較。

laterと類似したnpmパッケージ

laterは、Node.jsアプリケーションでのスケジュール管理を簡素化するためのライブラリです。特に、複雑なスケジュール設定を柔軟に扱うことができるため、時間に基づくタスクを簡単に管理できます。laterは、特定の時間や日付にタスクを実行するための強力な機能を提供しますが、他にも同様の機能を持つライブラリがあります。以下は、laterのいくつかの代替ライブラリです。

  • agendaは、MongoDBをバックエンドとして使用するジョブスケジューラーです。agendaは、タスクを簡単に定義し、スケジュールするための直感的なAPIを提供します。データベースにジョブを保存するため、アプリケーションが再起動してもジョブが失われることはありません。もしMongoDBを使用している場合、agendaは非常に便利な選択肢です。
  • cronは、Unix系オペレーティングシステムで広く使用されているスケジューリングツールで、Node.jsでも利用可能です。cronは、特定の時間や日付に基づいてタスクを実行するための非常にシンプルで強力な方法を提供します。特に、定期的に実行されるタスクが必要な場合に適しています。cronの構文は少し難しいかもしれませんが、非常に強力な機能を持っています。
  • node-scheduleは、Node.jsでのスケジュールタスクを簡単に管理するためのライブラリです。node-scheduleは、Cron形式のスケジュールとJavaScriptのDateオブジェクトを使用して、タスクをスケジュールすることができます。シンプルで使いやすく、特に小規模なプロジェクトや簡単なスケジュール管理に適しています。

これらのライブラリの比較を確認するには、こちらを参照してください: Comparing agenda vs cron vs later vs node-schedule。

node-cronと類似したnpmパッケージ

node-cronは、Node.jsアプリケーションでスケジュールされたタスクを実行するためのライブラリです。Cronの表現を使用して、特定の時間、日、週、月にタスクを実行することができます。node-cronはシンプルで使いやすく、Node.jsの環境で定期的な処理を簡単に設定することができます。しかし、node-cronには他にもいくつかの代替ライブラリがあります。以下にいくつかの選択肢を紹介します。

  • cronは、Node.jsでのスケジューリングをサポートするもう一つの人気のあるライブラリです。Unixのcronに基づいており、非常に柔軟で強力なスケジューリング機能を提供します。cronは、複雑なスケジュールを設定するのに適しており、特に多くのタスクを管理する必要がある場合に便利です。node-cronと同様に、cronもシンプルなAPIを提供しており、タスクのスケジューリングを簡単に行うことができます。
  • node-scheduleは、Node.js用のスケジューリングライブラリで、より高度なスケジューリング機能を提供します。特定の日時や繰り返しのスケジュールを設定することができ、柔軟性が高いです。node-scheduleは、cronの表現を使用することもできますが、JavaScriptのDateオブジェクトを使ってスケジュールを設定することも可能です。これにより、より直感的にタスクをスケジュールすることができます。

node-cron、cron、node-scheduleの比較については、こちらをご覧ください: Comparing cron vs node-cron vs node-schedule。

cron のREADME

cron for Node.js logo
cron is a robust tool for running jobs (functions or commands) on schedules defined using the cron syntax.
Perfect for tasks like data backups, notifications, and many more!

Cron for Node.js

Version Monthly Downloads Build Status CodeQL Status Coverage Renovate OpenSSF Scorecard Discord

🌟 Features

  • execute a function whenever your scheduled job triggers
  • execute a job external to the javascript process (like a system command) using child_process
  • use a Date or Luxon DateTime object instead of cron syntax as the trigger for your callback
  • use an additional slot for seconds (leaving it off will default to 0 and match the Unix behavior)

🚀 Installation

npm install cron

Table of Contents

  1. Features
  2. Installation
  3. Migrating
  4. Basic Usage
  5. Cron Patterns
  6. API
  7. Gotchas
  8. Community
  9. Contributing
  10. Acknowledgements
  11. License

⬆ Migrating

v4 dropped Node v16 and renamed the job.running property:

Migrating from v3 to v4

Dropped Node version

Node v16 is no longer supported. Upgrade your Node installation to Node v18 or above

Property renamed and now read-only

You can no longer set the running property (now isActive). It is read-only. To start or stop a cron job, use job.start() and job.stop().

v3 introduced TypeScript and tighter Unix cron pattern alignment:

Migrating from v2 to v3

Month & day-of-week indexing changes

  • Month Indexing: Changed from 0-11 to 1-12. So you need to increment all numeric months by 1.

  • Day-of-Week Indexing: Support added for 7 as Sunday.

Adjustments in CronJob

  • The constructor no longer accepts an object as its first and only params. Use CronJob.from(argsObject) instead.
  • Callbacks are now called in the order they were registered.
  • nextDates(count?: number) now always returns an array (empty if no argument is provided). Use nextDate() instead for a single date.

Removed methods

  • removed job() method in favor of new CronJob(...args) / CronJob.from(argsObject)

  • removed time() method in favor of new CronTime()

🛠 Basic Usage

import { CronJob } from 'cron';

const job = new CronJob(
	'* * * * * *', // cronTime
	function () {
		console.log('You will see this message every second');
	}, // onTick
	null, // onComplete
	true, // start
	'America/Los_Angeles' // timeZone
);
// job.start() is optional here because of the fourth parameter set to true.

// equivalent job using the "from" static method, providing parameters as an object
const job = CronJob.from({
	cronTime: '* * * * * *',
	onTick: function () {
		console.log('You will see this message every second');
	},
	start: true,
	timeZone: 'America/Los_Angeles'
});

Note: In the first example above, the fourth parameter to CronJob() starts the job automatically. If not provided or set to falsy, you must explicitly start the job using job.start().

For more advanced examples, check the examples directory.

⏰ Cron Patterns

Cron patterns are the backbone of this library. Familiarize yourself with the syntax:

- `*` Asterisks: Any value
- `1-3,5` Ranges: Ranges and individual values
- `*/2` Steps: Every two units

Detailed patterns and explanations are available at crontab.org. The examples in the link have five fields, and 1 minute as the finest granularity, but our cron scheduling supports an enhanced format with six fields, allowing for second-level precision. Tools like crontab.guru can help in constructing patterns but remember to account for the seconds field.

Supported Ranges

Here's a quick reference to the UNIX Cron format this library uses, plus an added second field:

field          allowed values
-----          --------------
second         0-59
minute         0-59
hour           0-23
day of month   1-31
month          1-12 (or names, see below)
day of week    0-7 (0 or 7 is Sunday, or use names)

Names can also be used for the 'month' and 'day of week' fields. Use the first three letters of the particular day or month (case does not matter). Ranges and lists of names are allowed.
Examples: "mon,wed,fri", "jan-mar".

📖 API

Standalone Functions

  • sendAt: Indicates when a CronTime will execute (returns a Luxon DateTime object).

    import * as cron from 'cron';

const dt = cron.sendAt('0 0 * * *');
console.log(`The job would run at: ${dt.toISO()}`);

  • timeout: Indicates the number of milliseconds in the future at which a CronTime will execute (returns a number).

    import * as cron from 'cron';

const timeout = cron.timeout('0 0 * * *');
console.log(`The job would run in ${timeout}ms`);

  • validateCronExpression: Validates if a given cron expression is valid (returns an object with valid and error properties).

    import * as cron from 'cron';

const validation = cron.validateCronExpression('0 0 * * *');
console.log(`Is the cron expression valid? ${validation.valid}`);
if (!validation.valid) {
	console.error(`Validation error: ${validation.error}`);
}

CronJob Class

Constructor

constructor(cronTime, onTick, onComplete, start, timeZone, context, runOnInit, utcOffset, unrefTimeout, waitForCompletion, errorHandler, name, threshold):

  • cronTime: [REQUIRED] - The time to fire off your job. Can be cron syntax, a JS Date object or a Luxon DateTime object.

  • onTick: [REQUIRED] - Function to execute at the specified time. If an onComplete callback was provided, onTick will receive it as an argument.

  • onComplete: [OPTIONAL] - Invoked when the job is halted with job.stop(). It might also be triggered by onTick post its run.

  • start: [OPTIONAL] - Determines if the job should commence before constructor exit. Default is false.

  • timeZone: [OPTIONAL] - Sets the execution time zone. Default is local time. Check valid formats in the Luxon documentation.

  • context: [OPTIONAL] - Execution context for the onTick method.

  • runOnInit: [OPTIONAL] - Instantly triggers the onTick function post initialization. Default is false.

  • utcOffset: [OPTIONAL] - Specifies time zone offset in minutes. Cannot co-exist with timeZone.

  • unrefTimeout: [OPTIONAL] - Useful for controlling event loop behavior. More details here.

  • waitForCompletion: [OPTIONAL] - If true, no additional instances of the onTick callback function will run until the current onTick callback has completed. Any new scheduled executions that occur while the current callback is running will be skipped entirely. Default is false.

  • errorHandler: [OPTIONAL] - Function to handle any exceptions that occur in the onTick method.

  • name: [OPTIONAL] - Name of the job. Useful for identifying jobs in logs.

  • threshold: [OPTIONAL] - Threshold in ms to control whether to execute or skip missed execution deadlines caused by slow or busy hardware. Execution delays within threshold will be executed immediately, and otherwise will be skipped. In both cases a warning will be printed to the console with the job name and cron expression. See issue #962 for more information. Default is 250.

Methods

  • from (static): Create a new CronJob object providing arguments as an object. See argument names and descriptions above.

  • start: Initiates the job.

  • stop: Halts the job.

  • setTime: Modifies the time for the CronJob. Parameter must be a CronTime.

  • lastDate: Provides the last execution date.

  • nextDate: Indicates the subsequent date that will activate an onTick.

  • nextDates(count): Supplies an array of upcoming dates that will initiate an onTick.

  • fireOnTick: Allows modification of the onTick calling behavior.

  • addCallback: Permits addition of onTick callbacks.

Properties

  • isActive: [READ-ONLY] Indicates if a job is active (checking to see if the callback needs to be called).

  • isCallbackRunning: [READ-ONLY] Indicates if a callback is currently executing.

    const job = new CronJob('* * * * * *', async () => {
	console.log(job.isCallbackRunning); // true during callback execution
	await someAsyncTask();
	console.log(job.isCallbackRunning); // still true until callback completes
});

console.log(job.isCallbackRunning); // false
job.start();
console.log(job.isActive); // true
console.log(job.isCallbackRunning); // false

CronTime Class

Constructor

constructor(time, zone, utcOffset):

  • time: [REQUIRED] - The time to initiate your job. Accepts cron syntax or a JS Date object.

  • zone: [OPTIONAL] - Equivalent to timeZone from CronJob parameters.

  • utcOffset: [OPTIONAL] - Analogous to utcOffset from CronJob parameters.

💢 Gotchas

  • Both JS Date and Luxon DateTime objects don't guarantee millisecond precision due to computation delays. This module excludes millisecond precision for standard cron syntax but allows execution date specification through JS Date or Luxon DateTime objects. However, specifying a precise future execution time, such as adding a millisecond to the current time, may not always work due to these computation delays. It's observed that delays less than 4-5 ms might lead to inconsistencies. While we could limit all date granularity to seconds, we've chosen to allow greater precision but advise users of potential issues.

  • Using arrow functions for onTick binds them to the parent's this context. As a result, they won't have access to the cronjob's this context. You can read a little more in issue #47 (comment).

🤝 Community

Join the Discord server! Here you can discuss issues and get help in a more casual forum than GitHub.

🌍 Contributing

This project is looking for help! If you're interested in helping with the project, please take a look at our contributing documentation.

🐛 Submitting Bugs/Issues

Please have a look at our contributing documentation, it contains all the information you need to know before submitting an issue.

🙏 Acknowledgements

This is a community effort project. In the truest sense, this project started as an open source project from cron.js and grew into something else. Other people have contributed code, time, and oversight to the project. At this point there are too many to name here so we'll just say thanks.

Special thanks to Hiroki Horiuchi, Lundarl Gholoi and koooge for their work on the DefinitelyTyped typings before they were imported in v2.4.0.

⚖ License

MIT

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. For more details, please refer to our Terms & Privacy.