Weave Code
Manager Laravel Package
puli/manager
Puli Manager provides the command-line tools for Puli, a PHP resource management system. It lets you initialize and configure repositories, map package resources, publish assets, and inspect resource paths across Composer packages.
Puli Manager is the orchestration layer of the Puli resource management ecosystem for PHP. It coordinates repositories, discovery, and URL generation so applications can reference assets, templates, and configuration files through logical paths (e.g. /app/assets/logo.png) rather than filesystem locations. The manager resolves these paths across multiple backends and keeps the mapping consistent between development and production.
- Unified resource repository API over local and remote backends
- Path resolution for logical resource names
- Pluggable discovery for locating resources across packages
- Consistent URL generation via configurable generators
- Integrates with Symfony and other frameworks through dedicated bridges
Frequently asked questions about Manager
- Is puli/manager a Laravel package?
- No. puli/manager is a framework-agnostic Composer library that owns read/write access to a project's puli.json manifest and the associated .puli/ metadata store. It ships no service provider, facade, config publisher, or Artisan command, so Laravel fit is effectively zero without bespoke glue code. Any integration you build is custom.
- How do I install puli/manager with Composer?
- Technically you can run composer require puli/manager, but the transitive dependency graph is a graveyard: webmozart/json, webmozart/key-value-store, puli/discovery, and puli/repository are all archived. Composer may resolve them and then pin your project to PHP 5.x/7.x-era constraints. On a modern Laravel app you would need --ignore-platform-req suppression, which is disqualifying for production.
- Does puli/manager support Laravel 9, 10, or 11?
- No. The package is compatible with PHP 5.x through 7.x only and pulls Symfony 2/3 components that collide directly with the Symfony 6/7 releases Laravel 9 and later depend on. There is no newer Puli release to upgrade to, so an in-place upgrade path does not exist. Do not attempt to force it onto a current Laravel version.
- What does puli/manager actually do?
- It validates, mutates, and persists the path mappings and package bindings stored in puli.json. Architecturally it sits between puli/repository, the on-disk key-value metadata store, and the puli/cli and puli/discovery tooling. That is a narrow configuration-management concern, not application runtime behavior.
- Is puli/manager still maintained?
- No. The last release was 2016-01-14, the upstream project is archived, there is no CVE pipeline, and there is no PHP 8 support. The package metadata is itself degraded, with the repository listed as unknown, which is a reliable signal of decay. Treat it as a migration target, never as a new adoption.
- Can I use puli/manager to resolve asset URLs at runtime in a Laravel app?
- You should not. If you must keep it around at all, treat Puli as a build-time configuration source only and never instantiate it inside the request lifecycle. The problem it solves, resolving /@vendor/package/resource style URLs across package boundaries, is now covered by Vite's manifest plus Laravel's asset() and resource_path() helpers.
- What are the alternatives to Puli for asset and resource management in Laravel?
- Laravel's own Vite manifest with asset(), resource_path(), public_path(), and filesystem disks cover the common cases, while Symfony Flex recipes and Composer 2's bin/extra conventions handle cross-package resource placement. For view paths you can use config/view.php entries instead of Puli mappings. The path-mapping abstraction is obsolete relative to a modern Laravel stack.
- What are the production risks of depending on puli/manager?
- Writes are file-based and non-transactional, so an interrupted puli.json write can desync the manifest from the .puli/ store with no built-in recovery path. Combined with an unmaintained upstream and no security response process, the technical risk is high. The MIT license is clean, but that is the only unambiguously positive signal.
- How do I migrate a Laravel application away from puli/manager?
- Freeze first: add no new manifest entries and pin the existing lockfile. Inventory every path mapping and binding in puli.json plus all call sites that resolve Puli resource URLs, then translate each entry to a Laravel-native equivalent such as a Vite alias, config/view.php path, filesystem disk, or public_path(). Dual-run behind a feature flag and diff resolved paths against Puli output before cutting over, then remove puli/* from composer.json, regenerate autoloads, and delete .puli/.
- How much effort does it take to remove puli/manager from a codebase?
- Roughly 3 to 5 sprints for a mid-size application: one sprint for assessment and codebase inventory, one to two sprints for the translation layer, one sprint for parallel validation, and about half a sprint for removal and cleanup. Effort scales with manifest size and the number of URL call sites, and call-site discovery usually dominates the estimate.
Weaver
How can I help you explore Laravel packages today?