Laravel Static Laravel Package

Product Decisions This Supports

• Capacity and cost planning for the page cache. static:status surfaces where disk is actually going (size by host, by file type, largest directories, largest files, age distribution), which turns "the webserver disk is full" from a recurring page into a sized, attributable number. That directly informs whether the next infrastructure decision is more disk, a cleanup job, or an architecture change.
• Whether query-string variants deserve product/engineering investment. The report explicitly quantifies cache bloat caused by ?utm_source=…, fbclid, and similar tracking parameters. That is the evidence base for a roadmap item — canonicalizing or stripping marketing parameters at the edge/middleware, or normalizing the cache key — rather than an opinion-driven refactor.
• Validating the compression decision. Because gzip/brotli siblings count toward size but not toward the page count, the report lets you confirm that enabling compression delivered net savings instead of quietly multiplying files. This supports a build-vs-buy call on whether to keep negotiating compression in the app or push it to the CDN.
• Prioritizing eviction/TTL work. The release restates that nothing leaves the cache short of a full static:clear, and that a file is written per URI including query string. Combined with the age distribution and variant counts, this is the strongest available argument for scheduling cache-hygiene work (scoped clearing, TTLs, variant caps) against other roadmap candidates.
• Choosing between app-level caching and a CDN. The per-host and per-file-type breakdowns, plus the parameter frequency table, give a concrete picture of what a CDN would absorb versus what the origin disk is currently carrying — useful input to a "keep, extend, or replace" review of the static cache.
• Incident and on-call readiness. --json output makes disk-usage alerting and dashboarding a config change rather than a project, which is a cheap reliability win and a credible answer to "how would we know before it pages us?"
• Scoping an internal cache-diagnostics tool. If observability of the cache layer was on the backlog as a build item, this release is a strong argument to buy/consume instead: a du-style report with pass-through collapse, parameter aggregation, and machine-readable output is not a half-day of work to replicate well.

When to Consider This Package

Consider adopting the package (or, if already using it, upgrading for this command) when:

• You run a Laravel application whose cacheable GET traffic dominates, and you are already writing static copies to disk — this release is additive diagnostics with no new runtime dependency in the request path.
• You have, or are about to have, disk-usage alarms or a full-disk incident and cannot currently answer "what is consuming the static cache?" without SSH and du/find guesswork.
• You suspect tracking-parameter multiplication (newsletter sends, ad campaigns, bot traffic appending utm_*, fbclid, gclid) is inflating storage, and you want numbers before proposing a fix.
• Your caching is local disk only, potentially very large (the release claims memory scales with distinct URL paths rather than file count, so multi-million-file caches remain diagnosable).
• You want automated monitoring — --json plus --limit allows a cheap cron probe and a threshold alert.
• You need a defensible input to a roadmap conversation about cache hygiene (eviction, TTLs, variant caps, parameter normalization) and want a repeatable measurement rather than a one-off investigation.

Look elsewhere, or scope expectations down, when:

• Your static cache lives on remote/object storage or a CDN — only local disks can be inspected; a remote walk would be one API round-trip per file, so this command will not serve you.
• You need per-entry lifecycle control (TTL, targeted invalidation, per-URL purge). This release improves visibility and offers one blunt lever (static:clear --only-with-query-strings), not lifecycle management. If eviction semantics are the actual requirement, this is still a gap — treat the command as a stopgap measurement tool, not a solution.
• You are looking for request-path caching features (tagging, warmup, stampede protection, stale-while-revalidate). That is out of scope for this release.
• You cannot accept operator-driven CLI hygiene as the operating model — the workflow implied here is "look at the report, then run a clear". Teams wanting policy-driven, automated cache management will find this insufficient on its own.
• You are multi-tenant with many hosts and need cross-host aggregation over time: --disk= targets individual disks and there is no built-in historical trending, so you would be stitching --json output yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): We run a static page cache that writes a file per URL to local disk, and until now we had no way to see what was in it short of logging into the server. A new release adds a single reporting command that tells us exactly where the disk is going — how much is real pages versus duplicate variants created by marketing and tracking parameters, which hosts and directories dominate, how old the content is, and how big the largest files are. The practical value is that a recurring "disk is full" operational problem becomes a measured number with an identified cause, and we can make a cost-versus-engineering trade-off on evidence instead of guesswork. It ships as a read-only command with JSON output, so it plugs into monitoring without new infrastructure and without any change to how requests are served.

For engineering leadership: This is a low-risk, additive release — an Artisan command plus a scoped clear flag, no stated breaking changes to caching behaviour. It closes the observability gap on a component that currently has no eviction story: nothing leaves the cache except a full static:clear, and query-string variants accumulate indefinitely. static:status gives us the data to justify the follow-on work (canonicalizing tracking parameters, TTLs or scoped clearing) with numbers attached, and --json makes a disk-usage alert trivial. Main constraints to note: local disks only, and no historical trending out of the box.

For engineering (the ask): Upgrade to v0.11.0, run static:status against production-equivalent disks, and bring the parameter table and per-host breakdown to the next planning session. Enable compression verification at the same time — compressed siblings count toward size but not page count, so we get a clean read on whether it is paying off. Then wire static:status --json --limit=N into monitoring with a threshold, so the next capacity conversation starts from an alert rather than an outage.