Services Loader Laravel Package

Product Decisions This Supports

• Extension/plugin architecture — build vs. buy. This package is a reference implementation of the "convention over registration" pattern: drop a service definition into a services.d directory and it gets loaded, instead of every new module requiring a hand-edit to config/app.php. That is the exact decision a PM faces when the roadmap starts including team-authored or third-party modules.
• Roadmap input on extensibility. If "marketplace," "plugin ecosystem," or "internal modules owned by other teams" is anywhere on the roadmap, the decision to make is what our extension-loading contract is. This package is a data point showing the cheapest possible version of that contract — and its adoption numbers are the argument for why the contract needs more than the minimum.
• Legacy/migration triage. Finding this in a composer.json is a reliable signal that the codebase predates Laravel 5.5 package auto-discovery and is very likely stuck on an old PHP version. That directly informs upgrade cost estimates.
• Decisions this should not drive. It should not short-circuit the prior question — "do we need a module system at all?" — and it should not be cited as precedent for adding a dependency. It is prior art, not a vendor.
• Not relevant to: performance, security posture, multi-tenancy, or any customer-facing feature. Nothing here touches the product surface.

When to Consider This Package

Adopt only under very narrow conditions:

• You are maintaining a Laravel ≤5.4 (or plain PHP / Slim / Silex) application from that era, already pinned to the same PHP constraint, and this is already in the lockfile.
• You need directory scanning and nothing else — no ordering guarantees, no enable/disable flags, no lazy loading, no dependency graph.
• You are treating it as a source to read and vendor, not a Composer dependency. It is MIT, small, and self-contained; copying the relevant portion into an internal class with tests is the only defensible consumption model.

Look elsewhere — and here "elsewhere" is mostly "the framework":

• Any new build. Laravel 5.5+ package auto-discovery, extra.laravel.providers in composer.json, or an explicit provider list in bootstrap/providers.php (Laravel 11) already solves this natively, with tests and a maintainer.
• Composer install risk. Last release January 2016; abandoned php/illuminate/support constraints will likely fail resolution or force you onto unsupported versions. That is an upgrade tax with no one to fix it.
• Bus factor. 1 star, 0 dependents, no release in roughly a decade, no issue triage. No one to patch a PHP 8.x deprecation, let alone a CVE.
• Requirements beyond the happy path. Ordering, lazy loading, feature flags, per-tenant module sets, or cached manifests — none of that exists here.
• Security surface. Code that includes files from a scanned directory is a code-execution surface. Acceptable when you own the directory outright; unacceptable in a shared or multi-tenant plugin scenario where contributors are untrusted.

How to Pitch It (Stakeholders)

Executives. This is not a purchase decision; the license is MIT and the cost is $0. The real cost is maintenance: a single-maintainer utility with no users, no release since 2016, and constraints that will block our next Laravel major. It solves a problem our framework has solved natively since 2016. Recommendation: do not add it as a dependency. If the ergonomics are genuinely useful to us, we reimplement the ~100 lines internally, own them, and test them — that is a day of engineering, not a procurement decision. Document the rejection so it isn't rediscovered in six months.

Engineering. Treat it as prior art worth thirty minutes of reading, not a dependency worth an hour of integration. The idea — discover and register service providers from a directory — maps directly onto Laravel's package auto-discovery and bootstrap/providers.php. If we want that behavior with our own guarantees, we build a thin decorator around the provider repository and add the things this package lacks: deterministic ordering, a manifest cache, an explicit allowlist of loadable paths, and tests. MIT-licensed source means we can borrow the scanning logic outright.

Framing to use in the decision log. "Rejected: unmaintained (last release 2016), no adoption (1 star, 0 dependents), functionality superseded by framework-native auto-discovery, and its file-inclusion model adds a code-execution surface we would have to own forever. Pattern noted for internal implementation if module extensibility reaches the roadmap."