Laravel Assets Laravel Package

Getting Started

Start by verifying the package against your Laravel/PHP version before adopting it. The last release was 2020-09-10 and the repository is not linked from the package metadata, so inspect vendor/kodicms/laravel-assets/composer.json, the service provider, facade, config file, and tests directly.

Minimal adoption path:

1. Install with Composer:

   composer require kodicms/laravel-assets
   

2. Check whether the service provider and facade are auto-discovered. If not, register them manually in config/app.php.

3. Publish the config if the provider exposes a publish tag:

   php artisan vendor:publish --provider="KodiCMS\\Assets\\AssetsServiceProvider"
   

   Confirm the exact provider class and tag from vendor/kodicms/laravel-assets/src.

4. Register your first assets in a service provider, usually AppServiceProvider::boot() or a dedicated AssetServiceProvider:

   // API names are illustrative; verify against the package facade/source.
   Assets::addStyle('app', asset('css/app.css'));
   Assets::addScript('app', asset('js/app.js'), ['defer']);
   

5. Render them from your main Blade layout:

   <head>
       {!! Assets::renderStyles() !!}
   </head>
   <body>
       ...
       {!! Assets::renderScripts() !!}
   </body>
   

The best first use case is a single layout-level asset registry: global CSS/JS in the layout, then page-specific additions from controllers or view composers.

Implementation Patterns

Centralize registration in one place. Put layout-level assets in a dedicated service provider or config file. This avoids scattering asset calls across controllers and views and makes ordering easier to reason about.

Use named groups or collections. Treat the package as a small registry:

• layout for global CSS/JS
• vendor for third-party libraries
• page for controller-specific assets
• inline for small bootstrap/config data

Render each group in the appropriate Blade partial.

Add page assets from controllers or view composers. For example, register a page-specific stylesheet only when a given view is rendered:

View::composer('reports.*', function () {
    Assets::addStyle('reports', asset('css/reports.css'));
});

Keep ordering explicit. If the package supports dependencies or priority, use them. If not, add assets in the exact order they must appear. Do not rely on registration order across multiple service providers unless you have verified it.

Wrap the package behind your own service. A small AppAssets wrapper isolates the rest of the application from the package API:

class AppAssets
{
    public function addLayoutAssets(): void
    {
        // package calls here
    }
}

This makes future replacement or forking much cheaper.

Use it as a tag registry, not a bundler. Continue using Vite, Laravel Mix, or your normal build pipeline. Give the package final URLs from asset(), Vite::asset(), or mix().

Test rendered output. In feature tests, assert that the response contains expected asset URLs and that page-specific assets do not leak into unrelated pages. This is especially important if assets are registered globally.

Gotchas and Tips

• Compatibility is the main risk. A 2020 release may not support modern Laravel versions. Pin Laravel/PHP constraints, run the test suite, and be prepared to fork or patch the package.
• GPL-2.0 requires legal review. If you distribute a proprietary application, confirm whether the license fits your distribution model before adopting the package.
• Documentation may be sparse. With 16 stars and no linked repository, treat the vendor source and tests as the source of truth. Check the facade methods, config keys, and render method signatures yourself.
• Auto-discovery may be absent. If assets do not render, first confirm the service provider and facade alias are registered.
• Clear caches after config changes. Run php artisan config:clear and php artisan view:clear when changing asset config or layout partials.
• Watch for duplicate includes. Use stable asset names/keys where possible. If the package does not deduplicate, your own registry should.
• Ordering bugs are common. CSS order matters for overrides; JS order matters for dependencies. Add a quick debug dump of registered assets before rendering when tags appear in the wrong order.
• Escape user content. Render methods likely output raw HTML. Never pass untrusted user input into asset names, URLs, or inline script content.
• CSP and SRI are probably not handled. If you need nonces, integrity hashes, or strict Content-Security-Policy support, verify whether the package accepts arbitrary attributes; otherwise post-process or extend it.
• Use absolute/application URLs. Prefer asset() or secure_asset() over hardcoded /public paths so deployments behind proxies and subdirectories behave correctly.
• Do not use it for complex dependency graphs. If your frontend needs real module resolution, code splitting, or tree shaking, keep that in Vite/Mix and use this package only for final tag placement.