- Does lightgear/asset support Laravel 5, 9, 10 or 11?
- No. It targets Laravel 4 exclusively, and its conventions (a service provider registered in app/config/app.php, illuminate/support ~4.x constraints, Blade-era tag helpers) do not fit Laravel 5 package auto-discovery or any modern pipeline. Laravel 5 through 8 use Laravel Mix and Laravel 9+ ships Vite as the first-party asset pipeline, so there is no architectural slot for a server-side PHP asset concatenator.
- How do I install lightgear/asset?
- The command is composer require lightgear/asset, but it will only resolve against a Laravel 4 dependency graph pinned to the PHP 5.4 to 5.6 era. Composer 2's stricter platform checks and modern PSR-4 autoloading expectations make installation on a current runtime a non-starter without patching the source. If you are on Laravel 4, register the service provider in app/config/app.php and publish the package config following Laravel 4 package conventions.
- Is lightgear/asset still maintained?
- There is no maintainer signal: zero stars, zero dependents, no issue history, no CI badge and no release cadence to inspect. There is no upstream to file CVEs against, which makes abandonment risk critical. Treat the repository as something that can disappear from Packagist without notice.
- What should I use instead of lightgear/asset?
- Use Laravel Mix on Laravel 5 through 8, and Vite with laravel-vite-plugin on Laravel 9 and later. If you need PHP-side tag generation with integrity or manifest lookups in a modern stack, a thin custom Blade component that reads Vite's manifest.json is roughly a day of work, fully owned and free of third-party risk.
- Can I run lightgear/asset on PHP 8?
- Assume PHP 5.4 to 5.6 only. PHP 8 removes deprecated constructs and tightens error semantics that packages of this era typically rely on, and Composer 2's platform checks will block resolution on a modern runtime. Do not assume PHP 7 compatibility either without reading the source first.
- Is lightgear/asset safe to use in production?
- Technical risk is high and not mitigable through normal vendor channels. The package performs runtime filesystem writes and exposes a cache directory, and its legacy minifier dependencies are unpatched; legacy PHP minifiers also commonly break on ES6+ syntax such as arrow functions, template literals and optional chaining. There is no upstream to receive fixes from.
- How do I use lightgear/asset in an existing Laravel 4 app that cannot move yet?
- Take the source into a private fork, using a vendored path repository or a private Packagist entry, and pin it to a commit SHA. Treat it as internal code rather than depending on Packagist availability for a package with zero dependents. Name an owner for the fork and tie its lifespan to that application's own migration off Laravel 4.
- Does lightgear/asset handle cache busting and concatenation?
- Yes, that is its 2013-era design: server-side concatenation of CSS and JavaScript plus cache busting, with helper methods rendering link and script tags from views and packages. Both problems now have maintained answers in Vite build output, hashed filenames and a manifest.json. It is also worth benchmarking request-time concatenation against simply pre-building static assets.
- What Laravel and PHP versions does lightgear/asset require?
- Laravel 4 exclusively, which pins PHP to roughly 5.4 through 5.6 and assumes Blade syntax predating the @push and @stack directives. Its illuminate/support constraint is ~4.x. Verify against the source before assuming compatibility with anything newer.
- Should I adopt lightgear/asset for a new Laravel project?
- No. The technical verdict is reject for new work: Laravel 4 reached end of life in 2015 and PHP 5.x has been unsupported since 2018/2019, so the runtime itself carries critical risk. If the requirement is anything other than a live Laravel 4 application, close it and build the asset step on Vite instead.