Laravel Dag Manager Laravel Package

Product Decisions This Supports

• Dependency-ordered feature work: Any roadmap item where steps or records must execute in a valid topological order (onboarding sequences, billing/fulfilment pipelines, content publishing chains, CI-style build graphs) can be modeled as a DAG instead of hand-rolled sort_order columns — this is a build-vs-buy call where the buy is a small, single-purpose library.
• Cycle prevention as a product guarantee: Because the package enforces acyclicity at the graph level, PMs can commit to user-facing promises like "no circular dependency can be saved" without bespoke validation code in every form request.
• Composable vs. rigid workflows: Supports deciding whether customers configure their own pipelines (DAG edges are data, not code) or whether the team ships a fixed sequence. The former unlocks a "workflow builder" roadmap item at low incremental cost.
• Platform currency as a roadmap gate: v5.0.0 adds Laravel 13 and PHP 8.5 support, which means the framework-upgrade roadmap item is no longer blocked by this dependency. Factor this into upgrade sequencing and support-window commitments.
• Migration/backfill planning: Topological ordering is directly useful for data migrations and seeding chores that must run in dependency order — often an internal-tooling win that pays for adoption on its own.

When to Consider This Package

Consider it when:

• You have a genuinely relational ordering problem — multiple parents, multiple children, partial ordering — not a simple linear list. If a single order integer expresses your domain, this is over-engineering.
• The graph is bounded and small-to-medium (tens to low thousands of nodes). It is an in-application graph library backed by your database, not a distributed scheduler or a job-orchestration platform.
• You need persistence of the graph (edges survive deploys, are editable by users or admins) rather than an in-memory resolution done once at boot.
• You want Laravel-native semantics — Eloquent models for nodes and edges, migrations, framework-version alignment — over a standalone PHP graph library you'd have to wire up yourself.
• You are already on, or moving to, Laravel 13 / PHP 8.5 and want dependencies that won't pin you back. The v5.0.0 support bump is the headline reason to be on this major.

Look elsewhere when:

• You need scheduling, retries, distributed execution, or observability — that's a queue/workflow engine (Laravel Horizon + jobs, Temporal, Airflow), not a DAG data structure.
• Your graph is large or highly dynamic with frequent full traversals at request time; per-node recursive queries can become a performance liability and you may want a purpose-built graph store or precomputed closure table.
• You need guaranteed support SLAs, security backports, or a commercial maintainer. This is a single-maintainer open-source package; treat it as a dependency you own, not a vendor relationship.
• Multi-tenant isolation or audit trails on graph mutations are hard requirements — expect to build that layer yourself.
• Your team would rather hand-roll a depends_on pivot with a recursive CTE — for one narrow use case, that may genuinely be cheaper than a dependency.

Note the v5.0.0 major bump: the only changes are a documentation/namespace fix in the custom DAG edge model example and added Laravel 13 / PHP 8.5 support. There is no reported API breakage, but a major version number is a signal to verify the custom edge model example against your own implementation and to run a full test pass, especially if you subclass the base node/edge models. Treat the major bump as a pin-and-test event, not a drop-in upgrade, and confirm the maintainer's release cadence before betting a tier-1 feature on it.

How to Pitch It (Stakeholders)

For executives: This is a small, focused open-source library that lets us model ordered dependencies as data rather than as hardcoded sequence numbers. That means we can ship customer-configurable workflows — a feature normally associated with much larger platforms — without building a workflow engine. It also just added support for the newest Laravel and PHP versions, so adopting it does not create an upgrade liability. The risk profile is low: it's a narrow dependency, not infrastructure, and it's replaceable if it stalls. The main caveat is that it is community-maintained with no vendor SLA, so we should treat it as code we own and pin the version.

For engineering: v5.0.0 is effectively a compatibility release — Laravel 13 and PHP 8.5 support, plus a corrected namespace in the custom edge model example. No deprecations or API changes are called out in the notes, but it is a major version, so budget a short spike: pin to v5, diff the example against any custom edge model we write, and confirm the cycle-detection and traversal paths behave identically to v4. Where this earns its place is anywhere we're currently maintaining manual ordering columns or recursive CTE helpers — that's duplicated logic with no cycle protection. Where it doesn't: anything resembling scheduling, retries, or large-scale graph traversal at request time. Those need a job orchestrator, and conflating the two is how this turns into a migration project.