Zipper Laravel Package

Product Decisions This Supports

• Feature bet: "Download all" as a first-class capability. For asset-heavy Statamic sites (photography portfolios, creative agencies, real-estate listings, media/press kits, document libraries), bulk download is a recurring end-user request. This package lets you expose that feature without building zip generation, storage, and cleanup plumbing yourself.
• Build vs. buy (buy, with a caveat). The core mechanic — enumerating Statamic assets and serving them as a single archive — is well-understood but fiddly to productionize (temp files, memory ceilings, MIME handling, filename collisions, cache invalidation, cleanup on failure). A small MIT addon collapses that to a route plus a config. Evaluate against ~1–3 engineer-days of in-house work, not against zero.
• Roadmap prioritization. It fits an "MVP / validate demand" slot rather than a "platform capability" slot. Ship it behind a flag, measure download volume and asset-set sizes, then decide whether bulk download graduates into a hardened, quota-controlled, authenticated product surface.
• Use cases to validate: client deliverable galleries ("download the full shoot"), press/media kits, bulk export for migration or backup, per-collection exports for internal ops, and seller/vendor asset handoff in marketplace-style apps.
• Repeated-download economics. The package supports caching generated archives, so popular sets (a press kit, a hero collection) can be served without re-zipping on every request. That is a real cost/latency lever — but it converts a stateless feature into one with a storage lifecycle you now own (disk choice, TTL, invalidation when assets change).
• Non-decision it helps you avoid: you do not need to commit to a background job queue plus object-storage lifecycle policy just to answer "can users grab everything at once?" — that is a meaningful infrastructure-hypothesis test before you spend on it.
• Licensing and procurement: MIT removes legal friction and vendor lock-in. The real cost is not license fees but the internal ownership of a lightly-adopted dependency.

When to Consider This Package

Adopt when several of these are true:

• You are already running Statamic on Laravel and assets live in Statamic Asset Containers (local or flysystem-backed).
• The job to be done is user-initiated, on-demand download of a selected or collection-scoped set of assets — not full-site archival.
• Asset sets per request are small-to-moderate (tens to low hundreds of files, predictable total size). Caching helps repeat requests, but first-generation cost and PHP max_execution_time / memory are still your ceiling.
• You want the feature this sprint and can accept single-maintainer risk in exchange for MIT licensing and a small, readable code surface.
• You are comfortable wrapping it: adding your own authorization, rate limiting, and audit logging around the download endpoint rather than relying on the package for those.

Look elsewhere or build in-house when:

• You are not on Statamic — the value is the Statamic asset-container integration; a generic Laravel zipper is a commodity and you should not couple to a niche addon.
• You need durable, auditable exports (large archives, resumable downloads, signed/expiring URLs, storage-tier lifecycle). That is a job-queue plus object-storage problem, not a route-level problem.
• You need access control, password-protected archives, per-tenant quotas, or billing metering — plan to own all of that yourself.
• Maintenance confidence is a hard requirement. Adoption signals remain thin (≈1 star, 0 dependents, short release history), though the project is actively patched. Not disqualifying for an internal utility, but disqualifying as a load-bearing dependency in a multi-year product without a documented fallback plan (fork-and-vendor is the realistic hedge).
• Compliance or data-residency constraints prohibit streaming assets through application servers, or require the archive to be produced in a specific region/storage boundary — note that archive caching writes asset bundles to a disk, which may widen the compliance surface.

Adoption checklist before commit: pin the version, read the source (small enough to audit in an hour), review the caching configuration explicitly — where archives are written, TTL, invalidation when underlying assets change, and whether caching can be disabled — write a contract test that asserts archive contents and filenames, and confirm behavior at your largest realistic asset set with a synthetic load test.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship a customer-visible "download everything" capability for asset-heavy parts of the product at roughly the cost of a route and a config file, using a permissively licensed open-source addon that fits our existing CMS stack. It supports caching of generated archives, so popular bundles can be served cheaply on repeat requests, and it lets us test real demand for bulk download before we invest in queue infrastructure and storage lifecycle management. The principal risk is not technical — the package is small, MIT-licensed, and actively patched — it is maintenance: it has minimal community adoption, so we should treat it as an internal utility we are prepared to fork and own, not a vendor relationship. Recommended: pilot behind a feature flag, instrument it, and revisit in one quarter.

For engineering (summary): Statamic addon that builds and serves zipped asset bundles; integrates with Asset Containers and supports archiving generated zips rather than always re-zipping on the fly. Latest patch (v2.5.1) fixes downloading a cached zip — a reminder that the cache path is the less-travelled branch and deserves explicit configuration and tests. MIT, small surface area, easy to read and fork. We own authorization, rate limiting, logging, cache disk/TTL/invalidation, and filename/edge-case behavior — do not assume the package handles them. Add a contract test on archive contents and on cache-hit vs. cache-miss responses, verify memory and execution-time behavior against our largest realistic asset set, review whether cached archives land on a disk with acceptable retention and residency properties, pin the version, and keep a fork path open given the low dependent count. If requirements drift toward large archives, resumable downloads, expiring links, or per-tenant quotas, escalate to a build decision rather than stretching this dependency.