Weave Code
Discovery Laravel Package
puli/discovery
Puli Discovery is a PHP library for locating and managing resources across packages. It provides a discovery API to register resource bindings, find files by type or path, and integrate resource lookup into Puli-based applications.
Puli Discovery is a PHP library for locating resources across Puli repositories. Rather than hard-coding file paths, you register repositories and query them by resource type (e.g. twig/template) or name, letting the discovery layer resolve which repository actually holds each resource. It builds on puli/repository and integrates with the Puli manager to expose a unified view of all registered repositories.
- Discover resources by type across every registered repository
- Resolve resources by name using repository preference ordering
- Inspect individual bindings and their repository metadata
- Iterate over matches lazily through
ResourceCollection - Works seamlessly with
puli/managerand the Puli CLI
Frequently asked questions about Discovery
- What is puli/discovery used for?
- It locates resources inside a Puli repository. It can discover files by type, path, or glob pattern across installed packages and publish the resulting artifacts, so callers avoid hard-coded filesystem paths for templates, assets, and configuration. It is a component of the Puli ecosystem rather than a standalone Laravel utility.
- Is puli/discovery a Laravel package?
- No. It is a component of the Puli ecosystem, a 2014-2016 attempt to provide package-relative resource addressing in PHP through puli.json mappings. It has no Laravel service provider, configuration, or integration. Using it means adopting surrounding Puli packages and a Composer plugin.
- Can I use puli/discovery with Laravel 10 or Laravel 11?
- Not realistically. Laravel 10 and 11 require PHP 8.1+, while Puli targets the PHP 5.x era and predates Composer 2 and modern PSR-4 conventions. Expect PHP constraint conflicts before runtime and likely fatal errors from old syntax. There is no supported integration path.
- Does puli/discovery work on PHP 8.1 or PHP 8.2?
- That is unverified and likely requires patching. The package has had no release since January 2016, and its code and dependency chain predate PHP 8. Fatal errors from removed or deprecated behavior are a realistic outcome, so treat any attempt as a throwaway spike rather than a production plan.
- How do I install puli/discovery?
- You would run composer require puli/discovery, but installation also pulls in the Puli manager, repository, and a Composer plugin that builds the repository during install or update. Composer 2 changed the plugin API and requires explicit allow-listing, so the install can fail before your application runs. Verify in a disposable branch and expect the plugin lifecycle to be the first blocker.
- Is puli/discovery still maintained?
- No. The last release was 2016-01-14, there is no active maintainer or security response process, and adoption is very small. The original documentation lived on a now-defunct project site, leaving 2015-era blog posts as institutional knowledge. Every PHP or Composer upgrade becomes your team's problem to diagnose.
- What are Laravel-native alternatives to puli/discovery?
- Laravel already solves cross-package resource location through Composer autoloading, package discovery, resource_path(), and Flysystem. For package views, assets, and config, use Laravel's package loading and publishing conventions rather than a separate repository layer. If you need glob-based manifests, a small per-package config file resolved by a service provider and cached with php artisan config:cache is usually enough.
- Why does puli/discovery require a Composer plugin?
- Puli builds its resource repository at install time, so the Composer plugin scans package directories and publishes artifacts during composer install or update. That makes the plugin a build-pipeline dependency, not just a runtime library. A single transitive failure can break composer install for the whole team.
- Is puli/discovery safe to use in production?
- It carries high, asymmetric technical risk. The code is unmaintained, has no CVE process, has unknown fork provenance, and pulls a dependency tree that is hard to audit from package metadata. On-call engineers would be reverse-engineering 2015-era behavior during an incident, so production use is not advisable.
- How do I replace puli/discovery with native Laravel code?
- There is no incremental migration because Puli's repository is generated by its Composer plugin. Instead, reimplement the narrow behavior you need: a small manifest per package, a service provider to resolve it, and config caching via php artisan config:cache. That is typically 100-200 lines and removes the entire dependency-risk surface. Document the decision so the question does not resurface.
Weaver
How can I help you explore Laravel packages today?