- Is jasonlewis/basset compatible with Laravel 8, 9, 10, or 11?
- No. Basset is a Laravel 4-era package built around manual provider and alias registration in app/config/app.php, package config publishing, and a classic facade and Artisan workflow. It does not support package auto-discovery or modern Laravel asset conventions. Using it on Laravel 8 or later would require a compatibility shim and a rewrite of the asset layer, not just a config change.
- How do I install jasonlewis/basset in a Laravel 4 application?
- Install it with Composer in a Laravel 4.x app running a compatible PHP version, then manually register the Basset service provider and facade alias in app/config/app.php. Publish the package configuration and define your asset collections and bundles. Basset assumes the pre-5.0 Laravel conventions, so there is no auto-discovery step.
- What PHP versions does Basset support?
- Basset is intended for Laravel 4.x applications on PHP 5.3 through 5.6. Its transitive dependencies, including lessphp, scssphp, and CoffeeScript PHP ports, pin old PHP constraints and are unmaintained. Composer resolution will commonly conflict with modern PHP runtimes, and the code can break on PHP 7 or 8 due to removed functions and dynamic-property behavior.
- Can Basset compile LESS, Sass, and CoffeeScript assets?
- Yes. Basset organizes CSS, JavaScript, and preprocessor files into bundles and uses filter-based compilation for LESS, Sass/SCSS, and CoffeeScript. Compiled output is written into public/assets through its build and cache pipeline. The package also provides Blade helpers and Artisan commands for building and serving those cached assets.
- Does Basset work with Vite or Laravel Mix?
- No. Basset does not integrate with @vite, Laravel Mix, or any Node-based toolchain. It is orthogonal to modern frontend pipelines and relies on its own filter, build, and local-disk cache model. For Laravel 9 and later, Vite is the native replacement; for Laravel 5.4 through 8, Mix is the usual migration target.
- Is jasonlewis/basset still maintained?
- There is no meaningful upstream activity, and the package reflects a dated, narrow user base rather than active adoption. Treat adoption as taking ownership of vendored code, including a named maintainer and a budget for fixes. It is effectively native only for an existing Laravel 4 application and has near-zero fit for a current codebase.
- What are the security risks of using Basset?
- The main exposure is unpatched transitive libraries such as lessphp, scssphp, and CoffeeScript PHP ports, which can pull known CVEs into your dependency graph. Runtime risk is also high because removed PHP functions and dynamic-property behavior will break on PHP 7 and 8. Cache invalidation and URL generation semantics are opaque, which can cause stale-asset incidents in production.
- How do I migrate from Basset to Vite or Laravel Mix?
- Treat the migration as a strangler-fig replacement rather than an upgrade. Inventory every asset Basset compiles and every Blade location that consumes the output, then stand up Vite for Laravel 9+ or Mix for 5.4 through 8 and emit to the same public paths and filenames. Run both pipelines in staging and diff emitted filenames, URLs, and rendered output before cutting Blade directives over per template. Finally remove the provider, facade alias, config, and cache directory.
- Why are my Basset assets stale or not updating?
- Basset uses a local-disk build and cache pipeline, and its cache invalidation and URL generation semantics are opaque. That makes stale assets a common source of production incidents, especially when deployments rely on CDN or immutable-container caching. Also verify that the cache and output directories are writable, because Basset assumes a writable local filesystem and read-only container filesystems violate that assumption.
- What are good alternatives to Basset for Laravel asset management?
- For modern Laravel, use Vite on Laravel 9+ or Laravel Mix on Laravel 5.4 through 8, configured to compile the formats you actually still use. For a legacy Laravel 4 app, the realistic options are maintaining a fork or replacing the asset layer entirely. There is no direct drop-in modern equivalent, so sequence the framework version decision before choosing the asset pipeline.