Composer Public Bundle Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package and cannot be treated as one. presta/composer-public-bundle is a Symfony 2 bundle — it hooks into the Symfony 2 Kernel/Bundle registration model, the DependencyInjection container, and the composer.json extra block consumed by a Composer installer plugin. Laravel's service-provider model, package discovery, and asset pipeline (public/, Mix/Vite) share no integration surface with it. There is no Laravel service provider, no facade, no config publish hook, and no supported path to register a Symfony bundle inside a Laravel application. The "Laravel/PHP package" framing in the request is a category error inherited from the source index; the correct read is "abandoned Symfony 2-era Composer asset-installer."

Integration feasibility. Effectively zero for a Laravel codebase. Even in its native Symfony 2 habitat it requires a contemporaneous Composer installer plugin (the composer/installers or composer-asset-plugin lineage) plus a composer.json extra schema that modern Composer 2 resolves differently or rejects. Adopting it would mean pinning Composer 1.x, which is itself end-of-life and unsupported. The bundle's purpose — declaring third-party JS/CSS in composer.json and having them fetched into the web root — is fully replaced by npm/yarn/pnpm plus Vite (Laravel) or Webpack Encore/Symfony AssetMapper (Symfony). There is no capability here that a modern front-end toolchain does not already do better, with lockfiles, integrity hashes, and security advisories.

Technical risk. Severe and non-mitigable. Last release 2014-02-25; repository archived; 3 stars, 0 dependents — no community to surface CVE reports, no maintainer to patch them, and no upstream to merge fixes into. The package predates PHP 7, so it will emit deprecations or hard failures on PHP 8.x (typed properties, each() removal, dynamic property deprecation, create_function removal). Its dependency constraints will almost certainly conflict with any modern symfony/* or composer/* requirement, producing unresolvable solver graphs. Supply-chain exposure is elevated: an archived, unpinned, low-visibility package is a poor place to source executable front-end assets. Risk cannot be reduced by configuration; only by not using it.

Key questions. (1) Is there a live Symfony 2 application still on this bundle, and if so, what is its PHP and Composer version? That is the only scenario where this evaluation has any operational meaning — and the answer triggers a migration, not an adoption. (2) What is the actual asset requirement behind the request: vendoring third-party JS/CSS into a Laravel app, or reproducing Composer-driven asset versioning? If the former, the answer is npm + Vite. (3) Is the package being surfaced by an automated index with a stale language classification? The 0.0525 score and 3 stars suggest exactly that, in which case the correct action is to drop it from the candidate list rather than evaluate further.

Integration Approach

Stack fit. None for Laravel. There is no supported composition path: no service provider to register, no config/ merge to publish, no asset directory convention that maps onto public/. Forcing it would require writing a bespoke adapter that fakes Symfony's bundle container — an unbounded maintenance liability for a capability already covered by first-party tooling.

Migration path. For a Laravel project, the migration path is away from this class of tool entirely: declare front-end dependencies in package.json, install with npm/pnpm, and build with Vite (the Laravel default since Laravel 9/10). For a legacy Symfony 2 project currently using it, the path is staged: (a) inventory every asset it currently fetches and the exact versions resolved; (b) freeze those versions into a package.json + lockfile or into committed vendor files; (c) introduce Vite or Symfony AssetMapper alongside the existing web/ output; (d) cut over template references asset-by-asset; (e) remove the bundle and its Composer installer plugin, then upgrade Composer to 2.x. Do not attempt an in-place version bump — there is no newer version to bump to.

Compatibility. Assume incompatible with PHP 8.x and Composer 2.x. If a proof-of-concept is demanded, budget for a throwaway branch, a pinned PHP 7.4 container, and Composer 1.x — and treat any success as a dead end rather than a foundation. Do not let that POC leak into a production dependency graph.

Sequencing. If any work is authorized at all, order it as: asset inventory first (this is the only durable artifact), replacement toolchain second, cutover third, decommissioning of the bundle fourth. Adoption is not a phase in this sequence and should be explicitly ruled out in the decision record so the question does not recur.

Operational Impact

Maintenance. Unmaintained by definition — archived, last release over a decade old, no dependents to inherit stewardship. Any defect becomes your team's defect to fix in a vendored fork, with no upstream to upstream to. Realistically this is a permanent fork obligation, which is a disproportionate commitment for a solved problem.

Support. None available. No issue triage, no security advisory feed, no release cadence, no maintainer contact. Internal support burden falls entirely on whoever inherits the code, and that knowledge will not be documented because the package is too obscure to attract community write-ups.

Scaling. The bundle's model — resolving front-end assets through Composer's PHP dependency solver — does not scale in the direction modern teams need: no tree-shaking, no content-hashed filenames for cache busting, no code splitting, no integrity attributes, no reproducible cross-environment builds. It scales fine in the trivial case (a handful of jQuery plugins) and fails structurally beyond it.

Failure modes. Dependency-solver deadlock on install; silent asset drift when the upstream URL a library was fetched from moves or disappears (a real risk for 2014-era CDN paths); PHP-version fatal errors during bootstrap; and the slow-rot failure where a build works on one machine's cached vendor tree and fails on a clean CI checkout. The last is the most expensive because it surfaces at the worst time and is hard to reproduce.

Ramp-up. Near-zero learning curve for the package itself, but negative ramp-up overall: an engineer who learns this toolchain learns a dead pattern that transfers to nothing. The genuine ramp-up cost is the migration work that adopting it defers — the team pays it later, with interest, on a compressed timeline. The TPM recommendation is to record the evaluation as "rejected — abandoned, out-of-ecosystem, superseded," and redirect the request to the current asset pipeline.