Php Zip Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for file packaging/export — this package sits on the "buy" side of the archive question, but its real value is as a forcing function. It wraps PHP's native ext-zip in a Symfony DI service; the decision it surfaces is whether a thin wrapper is worth a dependency versus ~100 lines of first-party code behind your own interface. Default answer for a Laravel codebase: build.
• Export & data-portability features — "download all," bulk report/invoice/media export, and account data handoff (GDPR/DSAR) as a single archive. This is the roadmap surface where zip capability actually appears.
• Deployment & admin tooling — packaging release artifacts, theme/plugin bundles, or admin-triggered backup snapshots in CI/CD or back-office workflows.
• Framework standardization — the package is a Symfony bundle, not a Laravel package. Adopting it in Laravel is a signal to revisit the framework/service-container boundary, not a drop-in feature decision. The Symfony Bundle/Extension/kernel registration mechanism is not portable to Laravel; only the ~100-line ZipArchive wrapper underneath is reusable, and that is the cheapest part to write.
• Vendor-risk policy — zero stars, zero dependents, score 0, single maintainer, no evident CI/tests/changelog/security policy. A concrete data point for defining your minimum bar for third-party dependencies (maintenance, CVE response, community size), especially for code that writes to the filesystem and extracts untrusted archives.
• Roadmap scoping — archiving is a secondary feature, not core product. Budget roughly one engineer-day to implement natively with an owned interface, rather than a dependency-plus-audit-plus-fork-and-own path.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is already Symfony and you want zip configuration (compression level, temp dir, path handling) managed through the service container and config/packages/*.yaml rather than scattered new ZipArchive() calls.
• Archiving is a secondary feature — you need it working, not optimized or streamed.
• You are willing to fork or vendor it, since there is no community, no dependents, and no maintenance signal.
• You have confirmed it is on Packagist with semver tags, checked the last commit date, and audited the extraction path for zip-slip, absolute paths, .. traversal, and symlink entries.

Look elsewhere (or build in-house) when:

• You're on Laravel. Use ZipArchive directly behind your own ArchiveService (create, extract, list, stream), or evaluate maintained Laravel-native options (spatie/laravel-zip for convenience, ZipStream-PHP for streaming). Pulling a Symfony bundle into Laravel drags symfony/dependency-injection and symfony/http-kernel for functionality you cannot invoke, and risks Composer constraint conflicts with Laravel's pinned symfony/console, symfony/http-foundation, symfony/process, and symfony/finder versions — potentially forcing a downgrade or failing resolution outright.
• Scale or streaming matters. ZipArchive reads the central directory up front and typically operates on a fully materialized file, so memory and temp-disk scale with archive size. Multi-GB exports, Zip64 (>4GB / >65k entries), or queue-worker concurrency need an explicit streaming design you own — per-job unique working dirs, queue-friendly timeouts.
• You need formats beyond zip (tar, gzip, 7z) or password/encryption handling with a defined security posture.
• Dependency hygiene is a requirement. No stars, no dependents, no release cadence means no signal that a broken ext-zip edge case or CVE gets fixed. For anything touching untrusted input, you want a track record or code you control.
• The environment isn't confirmed. ext-zip is not enabled by default in many PHP base images; libzip-dev + docker-php-ext-install zip must be in the runtime image, documented, and covered in CI. That failure surfaces at runtime, not install time.
• You need it to just work today. An unmaintained wrapper is a support burden you absorb, not a vendor you can escalate to.

How to Pitch It (Stakeholders)

To executives: This is a small, low-leverage utility — a thin Symfony wrapper around PHP's built-in zip extension — with no measurable adoption (0 stars, 0 dependents). It does not unlock new capability; PHP already ships with everything needed to produce zip archives, and our stack is Laravel, which does not consume Symfony bundles at all. Recommendation: do not add it as a production dependency. The archiving features on our roadmap can be delivered with native functionality in roughly one engineer-day, giving us full control, no supply-chain exposure, and no framework mismatch. If we later want a third-party option, this is not the one to standardize on.

To engineering: Treat it as a reference implementation, not a dependency. Wrap archiving behind a first-party interface (ArchiveService with create, extract, list, stream) so the underlying mechanism stays swappable; implement on ZipArchive for small/medium archives and switch to a streaming writer (ZipStream-PHP) if we hit memory or size ceilings. Enforce an explicit path-traversal guard and size/entry-count limits, and test against crafted malicious archives — zip-slip, zip bombs, symlink escape, non-UTF-8 entry names — not just happy-path round-trips. Bind via a Laravel service provider and keep the implementation swappable. If we ever adopt it anyway (e.g., an existing Symfony service already wired to it), pin the version, vendor the source, and audit filename/path handling before it touches user-supplied input. Note explicitly that a Laravel integration would require pulling in Symfony's container and config layers for negligible benefit.