Weave Code
Madzipper Laravel Package
madnest/madzipper
Madzipper is a Laravel package that wraps PHP’s ZipArchive with a fluent, chainable API for creating, extracting, and manipulating ZIP archives. Add files or folders, extract specific patterns, and manage archives using readable methods—ideal for backups, downloads, and file packaging in Laravel app...
Easier zip file handling for Laravel applications.
Frequently asked questions about Madzipper
- How do I install madnest/madzipper in a Laravel app?
- Run composer require madnest/madzipper and let Laravel package auto-discovery register the service provider and facade. You can then resolve the facade or inject it as a dependency; publishing config is optional. On older Laravel versions without auto-discovery, manually register the provider and add the Madnest\Madzipper facade alias in config/app.php. The whole setup typically gets you to a working archive in under an hour.
- Does madzipper support Laravel 13, and which Laravel versions can I use?
- Version 1.7.0 is reported as a single change: Laravel 13 support, which in practice almost certainly means widening the illuminate/support constraint rather than shipping new code. That makes it low risk for existing 1.6.x installs, but it is declared compatibility rather than verified compatibility. Before bumping, check the actual v1.7.0 diff and run your own test matrix against your Laravel version and PHP floor. Also confirm the widened constraint does not conflict with other packages pinning illuminate/support.
- What are the requirements for madzipper, and does it need the PHP zip extension?
- Madzipper is a thin wrapper over PHP's ext-zip and ZipArchive, so ext-zip must be compiled into every runtime image and CI runner. Debian-based php:*-fpm images usually ship it, while Alpine builds need libzip-dev present at build time. The failure mode is important: a missing extension fails at call time, not at composer install time. Add an extension assertion to CI so you find out before production does.
- How do I create a zip file and add files or folders with Madzipper?
- You start with the fluent make() entry point, chain add() calls for individual files or whole directories, and finish with close() to write the archive. Because the API is chainable, a backup or export routine reads as one readable statement rather than a sequence of ZipArchive calls. Paths are real filesystem paths, not Storage disks. You can also add content from strings and list the entries in the archive before closing it.
- How do I extract a zip file, or extract only specific files from an archive?
- Use extractTo() with a destination directory for a full extraction, or the pattern-based helpers when you only want entries matching a rule. This is useful for ingesting user-uploaded zips where you only care about certain file types. Extraction is synchronous and in-process, so check the return value and keep an eye on execution time for large archives. After extracting untrusted input, validate filenames and paths before moving anything into storage.
- Does madzipper work with Laravel Storage disks, S3, or Flysystem?
- No. Madzipper deliberately sits in the convenience layer and does not integrate with Flysystem or Storage disks; you hand it real local filesystem paths. For S3 or remote files, download to a temporary local path, build the archive there, then upload the result back through Storage. This is a design constraint rather than a bug, and it is worth accepting up front. If disk-abstraction semantics matter to you, a Flysystem zip adapter may be a better fit.
- Is madzipper a drop-in replacement for Chumper/Zipper?
- Largely yes, since Madzipper is a maintained fork of the original Zipper package. The migration is mostly a namespace and facade alias swap from Chumper\Zipper to Madnest\Madzipper, and the method surface is largely compatible. Audit the details anyway: make() versus zip() argument handling, close() semantics, and any getArchive() usage in your codebase. Run your existing archive tests before and after the swap.
- How does madzipper handle errors when a zip operation fails?
- Error handling is not exception-first on every path, and some operations return a falsy value instead of throwing. Call sites should check return values and wrap archive work in try/catch for anything ZipArchive itself raises. Do not assume a chained call succeeded because it did not blow up. For anything user-facing, fail loudly and log the archive path and operation so failures are diagnosable.
- Can madzipper handle large zip files, or does it stream archives?
- There is no streaming path. Zip and unzip work happens synchronously and fully in-process, which is a deliberate limitation of the wrapper. Memory limit and max execution time are your real ceilings, so establish realistic archive sizes and volumes before committing. For large or high-volume archives, push the work into a queued job, or drop down to native ZipArchive or a streaming-capable alternative.
- Is madzipper still maintained, and is it safe to use in production?
- It is a single-maintainer project with a low release cadence and terse changelogs, so bus factor and abandonment are the dominant long-term risks rather than code correctness. The code itself is straightforward, and the package has a long track record as the maintained successor to Zipper. If you adopt it, wrap it in your own ArchiveService so domain code never imports the facade directly. That keeps a future swap to native ZipArchive, a Flysystem zip adapter, or spatie/laravel-zip to a single class.
Weaver
How can I help you explore Laravel packages today?