Madzipper Laravel Package

Product Decisions This Supports

• Framework upgrade planning: v1.7.0 adds Laravel 13 support, which directly unblocks (or de-risks) a Laravel 13 migration for any product currently pinned to this package. This is the single most decision-relevant signal in the release.
• Build vs. buy for file archive/export features: Madzipper wraps PHP's native ZipArchive behind a fluent, Laravel-native API. It is a candidate dependency whenever the roadmap includes bulk export ("download all invoices/attachments/media as ZIP"), report packaging, backup snapshots, or tenant data portability.
• Delivery of customer-facing export UX: Supports features like streaming generated archives to the browser, adding files from storage disks, zipping Eloquent-backed file collections, and password-protected archives — all with low implementation cost.
• Maintenance burden triage: A small, single-purpose dependency with an active maintainer responding to framework releases is a low-carry-cost item; it rarely competes for engineering attention.
• Not a decision driver for: object storage lifecycle policy, CDN delivery, async/large-scale media processing, or anything needing resumable/large (>2 GB) archive generation — that belongs to a queue + streaming architecture decision, not this package.

When to Consider This Package

Adopt when:

• The product needs on-demand ZIP creation/extraction from PHP with modest archive sizes (tens to low hundreds of MB) generated within a request or a short queued job.
• You are on Laravel and want idiomatic integration (storage disks, config, facades) rather than raw ZipArchive calls scattered through the codebase.
• You want a thin abstraction that keeps archive logic testable and swappable, without pulling in a heavy document pipeline.
• You are planning or currently executing a Laravel 13 upgrade — v1.7.0 is the release that makes this package viable on that version.

Look elsewhere when:

• Archives are large or long-running: you need streaming/chunked writes, background workers, and progress reporting — build this around ZipArchive directly or offload to a job service.
• You need formats beyond ZIP (tar, 7z, gzip streams) — this is a ZIP wrapper.
• You require advanced compression control, encryption beyond basic password protection, or archive-level deduplication.
• The feature is infrastructure-adjacent (S3 batch operations, signed-URL delivery of pre-built archives) — cloud-native tooling may be the better fit.
• You cannot validate the package against your supported PHP/Laravel matrix — confirm Laravel 13 support only matters if you are actually moving to it; if you are on an older LTS, the prior 1.6.x line remains fine and this release is not a trigger to act.

How to Pitch It (Stakeholders)

For executives: This release is a compatibility update, not a feature release. Madzipper — the small library we would use to let customers download bundles of their files as a single ZIP — now supports Laravel 13. That removes a blocker from our framework upgrade path and keeps a low-cost dependency current. No new spend, no new vendor relationship, no migration required unless we choose to move to Laravel 13. Risk exposure is minimal: it is a thin wrapper over PHP's built-in ZIP support, so if we ever need to replace it, the underlying capability stays in the platform.

For engineering: v1.7.0 is a one-line change adding Laravel 13 support. Practical implications:

• Confirm our CI matrix includes Laravel 13 before adopting; the package's own test coverage is the only assurance we get, so pin the version and smoke-test our archive flows on upgrade.
• The API surface is unchanged from 1.6.x — this is a safe minor bump with no breaking changes, no deprecations, and no code changes expected on our side.
• Treat it as the sanctioned path for ZIP handling (fluent API over ZipArchive, storage-disk integration, model-based file collections). Keep archive generation inside a queued job if payloads can grow, and avoid it for very large or streaming exports.
• Because it depends on the zip PHP extension, verify that extension is present in our container images and CI runners — that, not the package, is the usual source of environment surprises.