Composer Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy (resources/asset resolution): Puli was an attempt to give PHP a package-level resource abstraction — logical names for templates, CSS, images and config that resolve across packages regardless of physical location. puli/composer-plugin exists solely to keep that abstraction in sync with Composer installs and updates. The decision this informs is whether we need a first-class resource layer at all; the market's answer (Puli was abandoned; the ecosystem standardized on PSR-4 autoloading, package-relative paths, Symfony Flex recipes, and front-end bundlers) is effectively "no."
• Roadmap triage: This is not a roadmap candidate. It is a migration line item. If it appears in our composer.json, the relevant decision is when we remove it, not how we extend it.
• Dependency and supply-chain governance: Because it is a Composer plugin, it executes code during install/update. That is a materially different risk class from a library. Composer 2.2+ allow-plugins makes this an explicit, auditable decision — good justification for a standing policy on which install-time plugins we permit.
• Reference architecture, not dependency: The one durable product value is the pattern — how to hook Composer script/plugin events to generate build-time artifacts (resource maps, manifests, cache warmers). That is directly reusable if we build our own Composer plugin for asset manifest generation or codegen.
• Feature scoping for legacy maintenance: If we support an older product line, this determines whether we invest in keeping a 2016-era toolchain green (pinned Composer 1.x, PHP 5.5–7.x) versus freezing that line and funding migration.
• Use cases where it was rational: plugin-based CMS/extension ecosystems with themes and swappable resources across packages; projects needing override semantics (a theme replacing a package's template) without hardcoded paths.

When to Consider This Package

Consider only if all of the following hold:

• An existing codebase already declares Puli resources in puli.json and depends on Puli's path resolution at runtime.
• The stack is pinned to PHP 5.5–7.x-era dependencies and Composer 1.x behavior, and CI is already frozen to match.
• The work is strictly bug-fix maintenance — no new features routed through Puli.
• You have quantified the blast radius: count of puli.json entries, puli:// / resource-ID references in code and templates, and plugin/theme packages that publish resources.
• You accept that there is no vendor, no support contract, and no security patching — last release 2016-03-31, 38 stars, single-maintainer lineage.

Look elsewhere when:

• New projects. Do not adopt. Use PSR-4 + __DIR__-relative paths, or a modern asset pipeline (Symfony AssetMapper / Webpack Encore / Vite) for front-end resources.
• Composer 2.x-era stacks. The Composer plugin API moved on; install-time plugin gating (allow-plugins) plus an unmaintained plugin is a governance and breakage hazard.
• You only need cross-package file discovery or copying. composer/installers, Symfony Flex recipes, or explicit Composer scripts cover most of it with maintained code.
• Security or compliance review is in scope. An unmaintained install-time plugin will not clear a modern dependency policy; expect it to be flagged and to require a documented exception.
• You need resource override/theme fallback semantics specifically. Reimplement narrowly on top of a maintained autoloader or container configuration rather than resurrecting a dead abstraction.

How to Pitch It (Stakeholders)

For executives (one paragraph): puli/composer-plugin is a small integration plugin for an abandoned PHP resource-management tool. It was last released in March 2016, has negligible community traction (38 stars), no active maintainer, and no security support. It carries above-average risk because Composer plugins execute code during dependency installation. It is not a strategic investment and not a build-vs-buy candidate — the capability it provided has been superseded by standard PHP conventions and modern asset tooling. Recommendation: treat it as technical debt, fund a scoped exit, and do not approve new adoption.

For engineering leadership:

• What it does: hooks Composer's install/update lifecycle to regenerate Puli's resource map so logical resource names resolve to real file paths across packages.
• Why it matters now: it is unmaintained and pinned to a pre-Composer-2 world. Every composer update is an unpatched code-execution surface gated only by allow-plugins.
• What we get by keeping it: zero new capability; only continuity for code already written against Puli resource IDs.
• What removal costs: mechanical but not free — inventory puli.json entries and resource-ID references, replace each with PSR-4 paths or a maintained asset mapper, then drop the plugin and the Puli dependency together. Scope is countable, which makes it plannable.
• What we should reuse: the plugin's event-hook approach as a reference if we ever need our own Composer-time manifest/asset generation — that pattern is sound even though the package is not.
• Ask: approve a time-boxed migration spike (inventory + one representative module converted) to convert this from an unknown-risk dependency into an estimated work item; adopt a written policy that install-time Composer plugins require explicit review and allow-plugins allowlisting.