Proposal: Modern Job Scheduling Integration with Monque

[ueberBrot]

Hi! 👋

The Problem with Current Integrations

I've previously used Ts.ED's @tsed/pulse integration and appreciated how natural the decorator-based approach feels within Ts.ED applications. However, I've run into the challenge that both underlying libraries are now effectively unmaintained:

• Agenda — Last meaningful update was years ago; open issues and PRs continue to stack up
• Pulse (fork of Agenda) — Officially archived on Oct 27, 2025; the repository is now read-only

This leaves Ts.ED users in a tough spot when choosing a MongoDB job scheduler with long-term reliability.

Introducing Monque

I've been working on Monque (pronounced "monk"), a modern MongoDB-backed job scheduler built from the ground up with TypeScript. It is currently in pre-release, but I believe the core architecture is solid and could be a great fit for the Ts.ED ecosystem.

Why Monque?

Feature	Description
🛡️ TypeScript-First	Full type safety with generics for job payloads — no type gymnastics required
🔒 Atomic Locking	Prevents duplicate job processing across multiple instances using MongoDB atomic operations
💓 Heartbeat Monitoring	Automatic stale job detection and recovery from crashed workers
📡 Change Streams	Real-time job notifications via MongoDB Change Streams (with polling as a fallback)
⏰ Cron Scheduling	Standard 5-field cron expressions for recurring jobs
🔄 Exponential Backoff	Configurable automatic retries with intelligent backoff
🔔 Event-Driven	Rich lifecycle events for observability and integrations
🔌 Framework Agnostic	Zero dependencies on any framework — easy to integrate

What's Different from Agenda/Pulse?

• Actively maintained — Regular updates and responsive to issues
• Modern TypeScript — Written in TypeScript from day one, not retrofitted
• Change Streams support — Real-time reactivity without aggressive polling
• Heartbeat-based recovery — More reliable stale job detection
• Cleaner API — Simpler, more intuitive interface

Roadmap

The roadmap already includes a planned @monque/ts-ed integration with:

• Decorator-based worker registration (@Worker, @Cron)
• Native lifecycle integration
• Type-safe job definitions

The Ask

I'd love to contribute a Monque integration for Ts.ED. Would you be open to accepting a PR to the Ts.ED monorepo (e.g., @tsed/monque under third-party packages)?

This would keep versions synchronized automatically with each Ts.ED release. A separate community package would work too, though it might not always stay in sync with the latest Ts.ED versions.

---

Resources:

• 📦 Monque Repository
• 📚 Documentation
• 🚀 Quick Start Guide

Thanks for your time and for building such a great framework! Looking forward to your thoughts. 🙏

[Romakita]

Hello @ueberBrot

Thanks for your proposal ;). But the creation of the pulse package for Ts.ED started like what you just did, with the same promises and the desire to offer an alternative to Agenda. The author of pulse asked me to develop the @tsed/pulse plugin and now we have a unmaintained module.

You project is young and haven't high visibility right know, so dedicating time to develop a tsed module to integrate your project won't possible. I don't want to reproduce the same story like Pulse.

The minimal things I can do is to reference your project as alternative in the doc with concrete example to implement your module. If you want to have a dedicated Ts.ED module, feel free to host the code in your repository to begin and publish it on NPM.

The crawler will automatically add your Ts.ED plugin if the NPM package name include the tsed term as it's explained here: https://tsed.dev/plugins/create-your-own-plugins.html

I'm sorry to not to be favorable at this step about your proposal right know, I am truly sorry and I hope you understand my point ^^. If you need any help about plugin creation, let me know ;).

This would keep versions synchronized automatically with each Ts.ED release. A separate community package would work too, though it might not always stay in sync with the latest Ts.ED versions.

Since v7 and v8, third parties aren't impacted by the Ts.ED changes. For the v9 I think I'll move the third-parties to another repositories because, having all third parties in the same repositories today, have more impact on CI perf, aren't updated often, create issue with dependencies.

Basically, the benefits of having them at the same level as the rest of the modules create more problems than benefits. For example, with Temporal, I have no control over it, no expertise to maintain it, and no idea how to properly set up its dependencies. The package authors haven't responded to my updated request, even though the Temporal version used by the package has become obsolete. If the authors had more often offered pull requests to maintain their plugins, I certainly would have responded favorably to your request.

[ueberBrot]

Hi @Romakita,

Thank you for the detailed and transparent explanation.

I completely understand your position. It makes perfect sense that you want to avoid a repeat of the "Pulse situation" where the core team is left inheriting the maintenance burden of a plugin you don't use personally.

Also, thank you for clarifying how third-party packages interact with core versions. I wasn't aware that they are now decoupled from internal changes; my main concern was that an external package might frequently drift out of sync or break with updates. Knowing that v7/v8 stabilized this makes the decision to go "external" much easier.

I will proceed with your suggestion to build this as a standalone community package hosted in the Monque repository and name it to satisfy the crawler.

Once I have the package published on NPM and the documentation ready, I’ll drop a note here so we can perhaps reference it in the docs as a modern alternative.

Thanks again for the guidance and for the offer of help regarding plugin creation. I appreciate it!