Confused about migrating from JSZip

[KTibow]

I really want to use this library instead of JSZip and improve performance, but a lot of stuff is confusing me.

• How do I get a list of files (and their metadata) without decompressing everything?
• How do I retrieve a single file?
• How can I get the comment from a zip?
• Will adding async into things worsen my performance and cause trouble with working on both CF Workers and browsers?

[101arrowz]

You can get a list of files via the filter callback in unzip and unzipSync. If you return false for every file and push the info parameter your filter receives into an array, fflate will decompress nothing. This does require fflate to parse the ZIP file twice, but it's pretty cheap.

const fileInfo = []
unzipSync(yourZipBuffer, {
  filter(info) { fileInfo.push(info); return false; }
})

You can extract a single file using a similar strategy, just return true with your filter for the one file you want to extract.

fflate does not expose access to the comment field within ZIP files unfortunately. You can make a feature request but I can't say it's a high priority as it's a very niche field that isn't always trivial to decode.

The async methods probably won't work on Cloudflare Workers as they use Web Workers or Node.js' worker_threads workers internally. They're really best used in web browsers to avoid blocking the main thread, and to decompress large zip files several times faster (because you can decompress the internal files in parallel).

[KTibow]

• Would it be possible to create a custom class or something that uses Unzip to emulate JSZip, where I have a list of files and can later start the stream later? I saw something about sometimes .start being called even if it wasn't explicitly, is that something to be worried about?
• Why is the comment hard to decode?
• Theoretically, if you made a Promise.all+async thing to decompress all the files, would it be faster? I know JSZip has a .async, does async not matter here since it's computation?

[101arrowz]

Emulating JSZip might not be trivial but I'll see if there's a way to make a wrapper that works like it.

The comment isn't hard to decode per se, it's just not possible to add without increasing bundle size by a good bit (maybe 2-3kB). It's extra complexity in a library that I've tried very hard to keep relatively bloat free, and comments are something that I've never seen used in the wild. If you do have a compelling argument for adding it though, I will add support for it.

unzip already sort of does a Promise.all equivalent internally - it decompresses the files in parallel. JSZip's async support is not similar to fflate's async support at all though - JSZip still blocks the main thread during decompression (which means it's actually slower than the synchronous version), while fflate sends the computation to a separate worker thread.

[KTibow]

Emulating JSZip might not be trivial but I'll see if there's a way to make a wrapper that works like it.

If you actually make a wrapper, cool, but I was just asking about how I could implement a per-file on-demand unzipping thing myself.

If you do have a compelling argument for adding it though, I will add support for it.

The only argument I have is my current use case: I have a program that analyzes .jars for malware, and usually when the zips have a comment, it means they're malware.

unzip already sort of does a Promise.all equivalent internally - it decompresses the files in parallel. JSZip's async support is not similar to fflate's async support at all though - JSZip still blocks the main thread during decompression (which means it's actually slower than the synchronous version), while fflate sends the computation to a separate worker thread.

I was just talking about async because I was trying to understand whether I should bother with async at all, what would be best for CF Workers, etc. It sounds like I should use async just in the browser.