- How do I install hollyit/filament-static-assets in a Laravel app?
- Install it with Composer using composer require hollyit/filament-static-assets, then let Laravel package discovery register the service provider. Publish any config or assets the README mentions, run your normal Filament publish/build step, and confirm the asset manager page appears in the panel. Pin the exact version you tested instead of a floating constraint.
- Which Laravel, Filament, and PHP versions does this package support?
- The Composer require block is the source of truth, so compare its Laravel, Filament, and PHP constraints against your exact stack before installing. The last tagged release was in March 2023, so do not assume support for newer Filament majors without testing. Pin the package version and document the tested combination in your repository.
- Does it publish assets at build time or require write access to /public at runtime?
- It is built for deployments where Nginx or Apache serves /public directly, so assets resolve as ordinary files instead of PHP routes. Whether publication happens at build time or at runtime depends on how you wire it into your pipeline, but running it in CI and shipping /public in the image is the safer choice. That avoids container permission problems and keeps admin assets identical across replicas.
- How is this different from Filament's native asset publishing or Vite?
- Filament's native asset publishing and Vite already place files under /public in most setups, so this package is mainly a convenience layer plus an admin UI for managing static files. It is useful when you want to browse, upload, and delete public assets from inside the panel without shell access. If your team already standardizes on Vite or a CDN pipeline, adding this is probably redundant and only increases dependency surface.
- How do I configure the package and can I change asset paths?
- Configuration is limited to what the package publishes plus how its page is registered, so publish the config if one ships with it and review the defaults first. Path changes usually mean adjusting where files sit under /public and making sure your web server serves those locations. Test any path change on staging, because a mismatch between the publish target and the served URL is the most common cause of broken panel styling.
- Does it handle cache busting, CDN, or remote asset hosts?
- No, the package does not add CDN behavior or versioned asset URLs; it just makes static files available in /public where a web server or CDN can serve them. Add cache busting through your build with hashed filenames or query strings, and apply long-lived immutable cache headers only to versioned paths. For multi-region or high-traffic deployments, front /public with a CDN and purge on deploy.
- How should I deploy it in CI and what smoke tests should I run?
- Run the asset publication step in CI or during the image build, then deploy the resulting /public contents rather than writing to disk at runtime. On staging, smoke test that the Filament login page renders with styles and that key CSS and JS URLs return 200. Compare response headers and cache behavior against your previous approach before cutting production over, and keep the old path available as a fallback.
- Why are Filament CSS and JS returning 404 after deploy, and how do I roll back?
- The usual causes are a publish path that does not match the URL the panel requests, files missing from the deployed artifact, or /public permissions inside the container. Check the built image for the expected files, curl the failing URLs, and confirm the web server document root. Rollback is simple because the package adds no database state: redeploy the previous image or revert the asset commit.
- Is this package still maintained and how risky is depending on it?
- Adoption is low, around 15 GitHub stars, and the last release was in March 2023, so treat it as a small utility your team may end up owning. The MIT license lets you fork, but there is no support SLA and only community issue support. Budget for periodic compatibility checks and a fork-or-replace contingency, and reassess at every Filament upgrade.
- What are the alternatives if I want to remove this dependency?
- Filament's built-in asset publishing, Vite, and a standard CDN-backed /public pipeline cover most of what this package does without extra dependencies. If you mainly need file management inside the panel, a dedicated Filament media library package may fit better. Keep this package only if the admin-page asset manager genuinely saves time and you have verified it against your Filament version.