Discovery Laravel Package

Product Decisions This Supports

• Evaluates whether to build or buy an asset/artifact discovery layer for a PHP package ecosystem, especially if the product needs packages to publish resources that other packages can discover automatically.
• Informs roadmap decisions around plugin/theme/package extensibility: whether resource discovery should be a first-class platform capability or delegated to package conventions.
• Supports architecture discussions for multi-package products where modules ship assets, templates, configs, or metadata that must be located without hardcoded paths.
• Helps decide whether to standardize on Puli-style artifact publishing/discovery versus Composer conventions, Symfony bundles, PSR standards, or a custom manifest.
• Relevant for legacy maintenance decisions: whether to keep, replace, or isolate an existing Puli dependency in an older PHP product.

When to Consider This Package

• Consider only if the product already uses Puli or a Puli-compatible package ecosystem and needs artifact publishing/discovery across packages.
• Consider for low-risk internal tooling, prototypes, or legacy maintenance where the dependency is already present and the team accepts an unmaintained package.
• Consider if the immediate goal is to understand historical Puli architecture before designing a modern replacement.
• Do not consider for new product development: the package is from 2016, has very low adoption, and belongs to an ecosystem that is effectively abandoned.
• Look elsewhere if you need active security maintenance, modern PHP compatibility guarantees, long-term vendor support, or broad community validation.
• Prefer Composer extra, Symfony Flex recipes/bundles, PSR-4/PSR-11 conventions, Flysystem, or a small internal manifest/discovery service for modern PHP products.

How to Pitch It (Stakeholders)

For executives: this is a very small, MIT-licensed PHP package for discovering artifacts published by multiple packages. It could reduce custom plumbing in a Puli-based system, but it is old, has minimal adoption, and is not a strategic dependency. Recommendation: do not adopt for new products; only tolerate it in legacy maintenance with an exit plan.

For engineering: the concept is useful—packages publish resources, consumers discover them—but the implementation is dated and tied to an abandoned ecosystem. Treat it as a reference architecture, not a foundation. If already used, isolate it behind an internal discovery interface so it can be replaced by Composer-based conventions or a custom registry without product-level rewrites.