Statamic Asset Usage Laravel Package

Product Decisions This Supports

• Scaling asset-heavy exports to enterprise accounts. PDF catalogs now hold 10,000 assets (up from 1,000) — a 10x ceiling lift that changes the answer to "can we support customers with large libraries?" from not really to yes, with caveats. This is the single biggest roadmap unblock in this release.
• Build vs. buy on export/reporting. The chunked generation model (500-asset parts joined browser-side) is a non-trivial engineering pattern — request isolation, client-side assembly, partial-failure handling. If your team was scoping "PDF export for asset libraries," this package now covers a requirement that would otherwise be a bespoke sprint.
• Storage and bandwidth cost planning. ~40% smaller thumbnails in PDFs directly reduces CDN egress and per-export payload size. At 10,000-asset scale, that compounds: fewer bytes per file, faster downloads, lower marginal cost per generated catalog.
• UX polish as a release signal. The filter-width fix (Overview and Compression pages) is minor but tells you the maintainer is addressing day-two usability, not just headline features — a positive indicator for a dependency you'd put in front of customers.
• Use cases this unlocks: customer-facing asset catalogs, brand/print proof sheets, internal audit exports of large media libraries, and any workflow where "select many → export to PDF" is a promised capability.

When to Consider This Package

Adopt when:

• You need PDF export of asset libraries at meaningful scale (thousands, not dozens) and the alternative is custom queue/chunking work.
• Your product already runs on Laravel/PHP and you want this capability without adding a separate service or vendor contract.
• Thumbnail storage/egress is a real cost line — the 40% reduction is a tangible win, not marketing.
• Your asset counts are in the low thousands to ~10,000. That's the documented ceiling in this release.

Look elsewhere or wait when:

• You need exports beyond 10,000 assets — the limit is explicit and the 500-per-part chunking implies real memory/request constraints. Confirm roadmap before betting an enterprise deal on it.
• You require fully server-side or headless PDF generation (batch jobs, scheduled reports). The browser-joins-the-parts design implies an interactive, client-driven flow — a poor fit for cron/API-only pipelines.
• You need strict SLAs, long-term support, or a commercial vendor behind the dependency.
• Breaking changes matter to you right now — this release is additive/fix-only, which is reassuring, but you should still pin versions and review the changelog each cycle.

How to Pitch It (Stakeholders)

To executives: This release removes a hard product ceiling. Customers with large asset libraries — the ones most likely to be on higher tiers — can now generate PDF catalogs covering 10x more content than before, at roughly 40% less file weight. Translation: we can serve bigger accounts with the same infrastructure, and each export costs us less in storage and bandwidth. Low risk: this is a feature-and-fix release with no breaking changes, so upgrading is not a migration project.

To engineering: The notable piece is the export architecture — PDFs are generated in 500-asset chunks and assembled in the browser rather than one long-running request. That's a deliberate trade to avoid request timeouts and memory blowups; worth understanding before we build adjacent features or attempt headless/batch exports, which this design does not currently support. Also note the hard 10,000-asset cap — treat it as a product constraint, not a bug, and validate it against our largest accounts. Filter-width fixes on Overview and Compression are cosmetic but confirm active maintenance. Recommend pinning the version and tracking the changelog for future breaking changes.