Composer Public Bundle Laravel Package

Getting Started

Read this first: this is a Symfony 2 bundle, not a Laravel package. It has no service provider, no facade, no config/*.php, and it was last released in February 2014 and is archived. There is nothing to composer require into a modern Laravel app, and the Composer plugin API it was built against (Composer 1.x era) will not load cleanly under current Composer versions. Treat this assessment as "should I copy the idea?" rather than "should I install it?"

If you are inheriting a legacy Symfony 2.3–2.8 codebase that already uses it, the minimal path is:

1. Open the README and find the composer.json extra block — that manifest is the source of truth for which public libraries (jQuery, Bootstrap, TinyMCE, icon sets, etc.) get pulled in.
2. Confirm the bundle is registered in app/AppKernel.php and that web/ is writable by the deploy user.
3. Run the console command the README documents (typically a presta:composer-public:* command) and watch what lands in web/.
4. First real use case: replacing a folder of hand-downloaded JS/CSS with version-pinned entries so an upgrade is a composer update plus a re-run of the command.

Where to look in the repo, in order: README.md → Resources/config/ (service wiring and the manifest schema) → the Command/ directory (what actually moves files onto disk) → composer.json (which Composer APIs it binds to).

Implementation Patterns

The mental model is "Composer as a front-end dependency manager." You declare a library and a target path, and the bundle copies the published files into your public web root. That maps onto four patterns you will actually meet:

• Manifest as the single source of truth. Every third-party asset is an entry in the Composer extra config, pinned to a tag or commit. Nobody downloads a .zip into web/js by hand. If you adopt the idea in Laravel, the direct translation is package.json + npm ci, not this bundle.
• Install-on-event. Wire the install command into post-install-cmd / post-update-cmd so a fresh clone becomes runnable after composer install. This is the one genuinely good idea in the package and it survives translation to any ecosystem — in Laravel you get the same behaviour from npm ci && npm run build in a Composer script or your deploy pipeline.
• Deploy-time materialisation. Assets are not committed; they are generated on the target. That means your CI/CD step must run Composer scripts and have write access to the public directory. Keep an explicit web/<vendor-libs>/ entry in .gitignore so a locally generated tree never gets committed by accident.
• Environment-specific pinning. In practice teams pinned different versions per environment by swapping the manifest, which is a smell. Prefer one locked manifest per branch and let the lock file do the pinning.

For a Laravel codebase, the honest translation of each pattern is: manifest → package.json; install-on-event → composer.json scripts calling npm ci; materialisation → npm run build (Vite/Mix) into public/build; environment pinning → package-lock.json per branch. Vendor-published assets (php artisan vendor:publish) cover the PHP-package-ships-static-files case that this bundle was invented for.

Gotchas and Tips

• It will not install on anything modern. The package predates Composer 2's plugin restrictions and Symfony's PSR-4/autowiring conventions. Expect composer require to fail on dependency resolution long before you hit a runtime error. Do not fight this.
• Archived and unmaintained. Three stars, zero dependents, no security response path. Any transitive asset it pulls is effectively unpinned from a supply-chain standpoint — the manifest references remote tags that can be moved or deleted.
• Hardcoded public path. The bundle assumes Symfony's web/ directory. In a Laravel app the equivalent is public/, but there is no configuration hook to tell it that, so any reuse means forking.
• No cache busting. Files land at stable paths, so browsers will happily serve stale JS after an upgrade. If you inherit this, add query-string versioning or a filename hash in your templating layer.
• Debugging a silent install. Run the console command with -v and check the exit code — file-copy failures in this era of Symfony often logged instead of throwing. Verify web/ ownership and that umask on the deploy user is not producing unreadable files served as 403s.
• Composer script ordering bites. If your post-install-cmd runs the asset install before the bundle's dependencies are autoloaded, you get a class-not-found with no useful trace. Chain the commands explicitly rather than relying on declaration order.
• Extension points are thin. The only realistic customisation is adding another manifest entry or a custom package type; there are no tests or docs to guide you, so budget for reading the command source directly.
• Verdict for day-to-day use: do not adopt. Use npm/yarn with Vite or Mix in Laravel, and if you are stuck maintaining a Symfony 2 app that depends on this, plan the migration off it as part of the framework upgrade — the asset pipeline (Assetic → Webpack Encore) changes at the same time anyway.