- How do I install Lasso in a Laravel application?
- Install it with Composer by running composer require sammyjo20/lasso from your project root, then review the published configuration file so you can declare your CSS and JavaScript bundles. Because bundle definitions live in configuration, you can keep environments consistent by committing a single config file instead of scattering asset lists across Blade templates. After installing, run your existing test suite once to confirm the Blade directive renders the expected URLs in your layouts.
- Which Laravel versions does Lasso support?
- The v3.5.0 release added support for Laravel 13 as a compatibility-only change, so that tag should install cleanly in a Laravel 13 application. The release note does not state explicitly whether Laravel 10, 11 and 12 remain in the support matrix, so check the composer.json constraint after requiring the package to confirm the widened range and the PHP floor. If you run multiple framework majors across services, verify the resolved dependency graph for each rather than assuming one constraint bump covers all of them.
- How do I define a CSS and JavaScript bundle with Lasso?
- You declare each bundle in the package configuration file, listing the assets that belong to it, then reference that bundle from your Blade templates instead of hand-writing individual script and link tags. Keeping the list in config means a bundle can be reused across layouts and environments without duplicating markup. If you need per-environment differences, use Laravel's standard config overrides rather than branching inside templates.
- What Blade directive does Lasso provide for including bundles?
- Lasso exposes a Blade directive so a single line in your layout outputs the tags for a configured bundle, which keeps header and footer markup short and consistent. The exact directive name and argument order are documented in the package README, so confirm that before adopting it across layouts. Once in place, adding a new asset to a bundle requires only a config change rather than editing every template. Remember to rebuild the config cache on deploy so the directive resolves the updated bundle contents.
- Does Lasso handle asset versioning and cache busting?
- Yes, the package supports versioning alongside caching, so bundle URLs can change when their contents change and browsers pick up new files instead of serving stale cached copies. This matters most for CSS and JavaScript, where aggressive browser caching otherwise hides updates after a deploy. Confirm how the version value is generated in your configuration before relying on it behind a CDN, and make sure your deploy step regenerates it rather than reusing a stale value.
- Is Lasso a replacement for Vite or Laravel Mix?
- No, Lasso organises and includes asset bundles but is not a compiler or build tool, so you still need Vite, Mix or another pipeline to produce the actual files. Think of it as the inclusion layer: the build tool emits versioned CSS and JavaScript, and Lasso groups those files into bundles you can pull into Blade. Teams that only need the default Vite helper in a standard Laravel app often do not need the extra abstraction.
- Will Lasso work with config:cache in production?
- Because bundles are defined in configuration, the package fits Laravel's normal config caching workflow, but you must run php artisan config:cache as part of each deploy after bundle changes, otherwise the cached config still points at the old asset list. Pair that with your existing cache-clearing and queue-restart steps so the whole deploy is deterministic. Test a full deploy in staging at least once, since a stale cached config is the most common reason a bundle change appears not to take effect.
- How should I test Lasso in a Laravel application?
- Add feature tests that request the pages using your layouts and assert the rendered HTML contains the expected bundle URLs, which catches config mistakes and missing assets before deploy. Run your whole application suite, not just Lasso's, after any Composer update, because the failure mode is usually a template error rather than a package exception. If you maintain multiple Laravel versions, run that suite on each target major, since framework support in a small package is often blocked by another dependency.
- Is upgrading to Lasso 3.5.0 risky?
- The release is compatibility-only: the only change described is adding Laravel 13 support, with no new features, deprecations or behavioural changes. In practice the work is a Composer constraint bump plus a full test-suite run on your target framework version. Branch the change, confirm the resolved dependency graph actually permits Laravel 13 alongside your other pinned packages, and canary one low-risk page in staging before merging.
- Is Lasso actively maintained and safe to depend on?
- It is a small, single-purpose dependency with a narrow surface area, which keeps the carrying cost low. One governance signal worth noting is that Laravel 13 support arrived through a first-time community contributor rather than a maintainer-driven release, which can indicate maintainer bandwidth constraints. Track release cadence and the issue tracker as part of dependency review, and pin to a caret constraint such as ^3.5 so patch and minor fixes land without surprise majors.