Laravel Schedule List Laravel Package

Technical Evaluation

Architecture fit. A single-purpose console package: it registers one service provider (via Laravel package auto-discovery) and contributes a schedule:list artisan command that introspects the scheduler's registered events and renders them as a table. There is no persistence, no configuration surface, no HTTP layer, and no coupling to application domain code. Architecturally it is about as low-risk as a dependency can be — it is a read-only diagnostic tool that answers "what is actually registered with the scheduler right now," a question most teams currently answer by grepping app/Console/Kernel.php and hoping nothing is registered conditionally. That is a genuine observability gap for on-call engineers.

Integration feasibility. composer require hmazter/laravel-schedule-list followed by auto-discovery; no config publishing, no migrations, no env changes. A spike is under an hour on a known-good version pair. The binding constraint is version compatibility, not integration effort: the package's last release is December 2020, which predates Laravel 9/10/11, PHP 8.1+, and Symfony Console 6. Treat it as a candidate for legacy applications only until proven otherwise.

Technical risk. The security surface is effectively nil (local CLI, no external input, no network, no filesystem writes). The risks that matter are:

• Obsolescence / conflict. Laravel shipped a native schedule:list command in 8.37+. On modern applications this package is either redundant or a command-name collision, which is a confusing failure for the exact audience that runs it during incidents.
• Misleading output. An inventory tool that silently omits entries (Schedule::call closures, custom events, sub-minute tasks) or mis-renders cron/timezone/constraint metadata is worse than no tool, because engineers will trust it. This is the highest-severity failure mode and the hardest to detect.
• Upgrade drag. A stale dependency in composer.lock becomes an audit finding and can block a framework upgrade if its illuminate/* / symfony/console constraints conflict.

Key questions.

1. What is the Laravel/PHP version distribution across our fleet, and which apps are below 8.37 (i.e., lack the native command)?
2. What does the native schedule:list already give us, and what gap (next-run times, human-readable cron, mutex/overlap state, output capture) remains after that?
3. Do our schedules use closures, custom events, sub-minute frequencies, or runtime-conditional registration — the cases this parser is most likely to under-report?
4. Is the command needed in production for runbook/incident use, or is dev-only acceptable? That determines require vs require-dev.
5. Who owns the fork if the upstream maintainer stays inactive?

Integration Approach

Stack fit. Composer + Laravel + PHP is our baseline, so there is no stack impedance. The decision is packaging policy: prefer require-dev so the deploy artifact and production dependency graph stay clean, unless we explicitly want the command available during production incidents — in which case accept the extra production dependency and document it.

Migration path. For Laravel ≥ 8.37 the correct move is to adopt the framework's native schedule:list and not add this package at all. This package's value is confined to applications pinned below that line, or to cases where its output format is materially richer than native — verify that claim side-by-side before assuming it. If richer output is still required, the highest-leverage path is a ~50–150 line internal command or a small fork under our org, pinned to a commit and carried with a patch set; the logic is thin enough that forking is cheaper than dependency risk management.

Compatibility. Validate per application with composer why-not hmazter/laravel-schedule-list against the pinned PHP and Laravel versions, and specifically probe the Illuminate scheduling API surface it touches (Schedule event collection, event display/summary methods, symfony/console table APIs). Note that Laravel 11 relocated schedule definition out of app/Console/Kernel.php (into routes/console.php / bootstrap/app.php); the package operates on whatever is registered into the Schedule instance, so it should still function, but the surrounding assumptions in its README and any kernel-path assumptions deserve a direct test rather than an inference.

Sequencing.

1. Inventory the fleet by Laravel/PHP version; flag everything ≥ 8.37 as "native command, no action."
2. Spike the package on the most common legacy version, not the newest.
3. Diff its output against the native command and against the scheduler source of truth on the same app.
4. Decide per cohort: native / package-as-stopgap / fork / build internal.
5. Only after that decision, add the chosen mechanism to on-call runbooks — the tooling is worthless if nobody knows it exists during an incident.

Operational Impact

Maintenance. Near-zero runtime maintenance; the entire cost is dependency hygiene. A 2020-vintage package sitting in composer.lock with no path to updates generates recurring security-audit and upgrade-planning noise disproportionate to its value. If adopted broadly, budget a one-time fork and ownership assignment (~1–2 engineer-days) rather than carrying the upstream package indefinitely.

Support. Single-maintainer OSS, 94 stars, issue-tracker support only, no SLA, no release in over four years. That is acceptable for a developer convenience command and unacceptable for anything on the incident-response critical path unless we own the fallback. Set that expectation explicitly before someone puts it in a runbook.

Scaling. Non-issue. CLI-only, single-process, no queries, no memory growth, no runtime overhead on requests or queue workers. Cost scales linearly and trivially with the number of scheduled commands. It cannot affect application throughput.

Failure modes.

• Command fails to register, or collides with the native schedule:list, producing duplicate or shadowed behavior.
• Fatal error on incompatible Illuminate/Symfony versions — loud, which is the good case; caught in CI or at first invocation.
• Silent misreporting of closures, custom events, conditional registration, timezone, or constraint metadata — quiet, which is the bad case, because it corrupts the mental model of the person debugging a missed run.
• No next-run or last-run computation: it answers "what is scheduled" but not "what runs next / what just ran," which is usually the actual on-call question. Pair it with scheduler logging or a monitoring integration rather than presenting it as sufficient.

Ramp-up. Minutes for any Laravel developer to install and read. The real ramp is organizational: teaching the team when the output is authoritative versus approximate, and pairing it with run history. Budget a short note in the runbook rather than formal training.

Bottom line. Low architectural risk, low integration cost, low operational burden — but the package's core value has been absorbed upstream and its maintenance is effectively ended. Default to the framework's native schedule:list; consider this package only as a time-boxed stopgap for pre-8.37 applications, and prefer a small internal fork over a long-lived dependency on an unmaintained package.