Composer Plugin Laravel Package

Technical Evaluation

Architecture fit: Poor for a modern Laravel application. puli/composer-plugin is a Composer build-time integration for Puli, a resource/path-management abstraction that predates and overlaps with Laravel’s own package discovery, service providers, config publishing, and asset publishing conventions. It does not provide Laravel-specific value. It only fits a legacy codebase that already depends on Puli and expects Puli resource discovery/path mappings.

Integration feasibility: Low unless Puli is already in the dependency graph. The package is a Composer plugin, so adoption requires plugin allowlisting in Composer 2 (allow-plugins), compatibility with the project’s Composer and PHP versions, and confidence that generated Puli artifacts are reproducible in CI. The last release was 2016-03-31; Composer 2, PHP 8.x, and modern Laravel are outside its original support envelope. The repository field is unknown, increasing provenance and support risk despite the MIT license.

Technical risk: High. Primary risks are abandonment, Composer plugin API incompatibility, old transitive dependencies, build-pipeline execution risk, stale or non-deterministic generated resource mappings, and lockfile/CI drift. The plugin executes during Composer install/update, so failures can block dependency installation or produce artifacts that differ between developer machines and CI. The 38-star adoption level implies limited community validation and few maintainers.

Key questions:

• Is puli/puli or puli/composer-plugin already present transitively? Run composer why puli/composer-plugin and composer why puli/puli.
• Does any application code actually consume Puli resource paths, or is this only a legacy build artifact?
• Which Composer and PHP versions must be supported? Does the plugin load under Composer 2 with allow-plugins enabled?
• What files/artifacts does the plugin generate, and are they committed or rebuilt in CI?
• Can Puli resource lookups be replaced with Laravel/Symfony path helpers, Composer autoload metadata, or Laravel package discovery?
• Is there an internal owner willing to fork and patch the plugin if Composer/PHP upgrades break it?
• What is the supply-chain provenance given the unknown repository and 2016 release?

Integration Approach

Stack fit: Weak for greenfield Laravel. Prefer native Laravel mechanisms: package discovery, service providers, config/asset publishing, base_path()/resource_path()/public_path(), and Composer autoloading. Consider this plugin only as a compatibility shim inside a legacy Puli-based application.

Migration path: First inventory actual Puli usage. If the plugin is only transitive, attempt removal and run the full test suite. If Puli paths are used, replace them incrementally with Laravel/Symfony path resolution or explicit package configuration, then remove Puli dependencies. If immediate removal is impossible, pin the plugin and Puli versions, isolate the legacy package, and plan a fork or compatibility patch rather than adopting it for new code.

Compatibility: Validate against the exact Composer and PHP matrix. Confirm composer-plugin-api constraints, Composer 2 plugin allowlisting, PHP 8 deprecation/fatal behavior, and CI reproducibility. Test clean installs from lockfile, not only incremental updates. Because the last release is from 2016, assume incompatibility until proven otherwise.

Sequencing:

1. Run dependency and usage inventory (composer why, code search for Puli namespaces/configuration).
2. Create a short compatibility spike on a branch with the target PHP/Composer versions.
3. If required, add allow-plugins configuration and lock versions; verify generated artifacts in CI.
4. Replace Puli resource resolution with Laravel-native paths/package discovery.
5. Remove the plugin and Puli dependencies once no references remain.
6. For greenfield work, do not introduce the plugin; document the decision.

Operational Impact

Maintenance: High. The package is effectively unmaintained, old, and low-adoption. MIT licensing permits forking, but the team would own patches, compatibility testing, and security review. Puli itself must also be assessed as an abandoned dependency.

Support: Minimal. Expect no upstream support, limited issue history, and sparse documentation. Internal documentation and an explicit owner are required if retained. The unknown repository is a governance concern.

Scaling: Mostly build-time impact. Composer install/update and CI jobs may slow down due to resource discovery and repository generation. Runtime scaling is unlikely to be the main issue, but generated Puli repositories must remain consistent across environments. Cache Composer dependencies and generated artifacts carefully.

Failure modes: Composer plugin API incompatibility can block installs; disabled allow-plugins can silently or explicitly prevent plugin execution; PHP 8 incompatibilities can fatal during install; stale or corrupt Puli repositories can cause missing resources; path mappings can collide; CI may generate different artifacts than local environments; abandoned transitive dependencies may carry security vulnerabilities; and plugin execution adds build-time code-execution risk.

Ramp-up: Moderate to high. Laravel developers will need to learn Puli’s resource/package model plus Composer plugin lifecycle behavior. Because documentation is old and community knowledge is thin, budget for a spike, a written compatibility note, and a containment plan. Treat this as legacy maintenance work, not a strategic Laravel dependency.