Discovery Laravel Package

Technical Evaluation

Architecture fit. puli/discovery is not a Laravel package — it is a component of the Puli ecosystem, a 2014–2016 attempt to give PHP a uniform, package-relative resource addressing scheme (/app/views/foo.html.twig resolved through per-package puli.json mappings). Discovery scans package directories, matches glob patterns, and publishes the resulting artifacts into a Puli repository. Adopting it means adopting the surrounding stack (puli/manager, puli/repository, the Composer plugin that builds the repository at install time), not adding one dependency. Laravel already solves the narrow problem it targets — cross-package asset/view/config location — through Composer autoloading, package discovery, resource_path(), and Flysystem. There is no architectural gap here that Puli fills.

Integration feasibility. Low. The package is nine years old (last release 2016-01-14), predates Composer 2, and its repository is not even indexed for review. Installation would drag in an abandoned Composer plugin that must run during composer install/update — a lifecycle hook whose API Composer has changed since. Whether it works at all on PHP 8.1+ is unverified and likely requires patching for removed/deprecated behavior.

Technical risk. High and asymmetric. Unmaintained code, no security response process, unknown fork provenance, tiny adoption (11 stars), and a dependency tree we cannot audit from the metadata provided. A single transitive failure breaks composer install for the whole team, which is a build-pipeline risk, not just a runtime one.

Key questions.

• What concrete problem are we solving — asset discovery across our own packages, or cross-vendor resource resolution? The answer likely changes the recommendation from "no" to "definitely no."
• Is any part of Puli already transitively present in our lockfile? If so, we have latent exposure regardless.
• Who owns a fork if we vendor it, and for how long?
• What does the equivalent Laravel-native implementation cost — an afternoon, or a sprint?

Integration Approach

Stack fit. Poor for any current Laravel line. Laravel 10/11 require PHP 8.1+; Puli targets the PHP 5.x era with a glob/path-utility dependency chain that predates modern PSR-4 conventions. Expect version conflicts on PHP constraints alone before you reach runtime errors.

Migration path. There is no incremental path — Puli is all-or-nothing because the repository must be generated by the Composer plugin. If a specific Puli behavior is genuinely valuable (e.g., glob-based artifact patterns declared in package manifests), the realistic path is to reimplement that narrow behavior behind our own interface: a small config manifest per package, resolved by a service provider, cached with php artisan config:cache. That is roughly 100–200 lines and removes the entire dependency-risk surface.

Compatibility. Two blockers are near-certain: the Composer plugin lifecycle (Composer 2 changed plugin API and requires explicit allow-listing) and PHP 8 fatal errors from old syntax. Neither is a configuration tweak; both are fork-and-patch work on code nobody maintains.

Sequencing. (1) Confirm the real requirement with the requesting engineer. (2) Timebox a one-day spike in a throwaway branch to see if it installs at all on our PHP version — treat failure as the expected outcome and a reason to stop. (3) If the spike succeeds, quantify the fork cost. (4) Default to the native alternative and document the decision so the question does not resurface.

Operational Impact

Maintenance. Effectively unbounded. No releases since January 2016, no maintainer, no CVE process. Every PHP or Composer upgrade becomes our problem to diagnose in code we did not write and cannot upstream.

Support. None. No vendor, no active community, and the original documentation lives on a defunct project site; institutional knowledge is blog posts from 2015. On-call engineers will be reverse-engineering behavior during an incident.

Scaling. Discovery is a build-time operation, so runtime cost is low if the repository is correctly cached and shipped. But repository generation grows with package count and file count, and it runs inside every CI job and every developer's composer install — a slow, opaque, frequently-broken step in the critical path of the whole team.

Failure modes. Composer plugin failure or silent no-op during install; stale discovery cache after deploy producing missing-asset errors in production; path-resolution mismatches between environments; hard fatals on PHP minor upgrades; and, worst case, an unpatched vulnerability in an unauditable transitive dependency.

Ramp-up. Two to three weeks for a competent engineer to build a correct mental model of Puli paths, bindings, and repository semantics — invested in a dead ecosystem. The native alternative has near-zero ramp-up because the team already knows it.

Verdict. Do not adopt. The score, the abandonment date, the adoption level, and the missing repository index all point the same way, and the capability is already covered by the framework. Recommend the native/reimplement path and record the rationale in the decision log.