Is "uzip-module" deprecated in favor of "unzipit" and "zipup"?

[mehradotdev]

Hi, thank you for creating this library. I came here from an issue from photopea/UZIP.js photopea/UZIP.js#9 (comment)

But I quickly found out you also made 2 other libraries. That are "unzipit" and "zipup". Which are not based on photopea's UZIP.js implementation. I think they are based on "yauzl" and "yazl" libraries.

I have few questions for you:

1. Is "uzip-module" library depreacted in favor of "unzipit" and "zipup"? If yes, what was the reason for leaving photopea's UZIP.js implmentation and creating 2 separate libraries for zipping and unzipping?
2. I like photopea's UZIP.js library because it is very small and good performance. Are "unzipit" and "zipup" also small and have good performance compared to UZIP.js?
3. Would you be interested in a PR to "uzip-module"? I have created a typescript port of UZIP.js. Which has proper tree shakablity and built-in type inference, etc. This typescript port was created using GPT-5.4 and code reviewed by Opus 4.6.
   And I have fixed some bugs too like

• fix: use exact extension matching for no-compression file types photopea/UZIP.js#20
• fix: full unicode filename handling in 'writeUTF8' and 'sizeUTF8' photopea/UZIP.js#21

Later we can add documention for uzip-module in github.io if you want.

[greggman]

Thank you for reaching out

1. Is "uzip-module" library depreacted in favor of "unzipit" and "zipup"? If yes, what was the reason for leaving photopea's UZIP.js implmentation and creating 2 separate libraries for zipping and unzipping?

the uzip-module was just pure JavaScript implementation of the "deflate" algorithm. It was not and never has been a "zip" library. It has no concept anything related to zip. It was just the decomprssion part. Hand it some bytes and it decompresses them into more bytes. It's no longer needed as DecompressionStream provides "deflate" and is built into both the browser and node.

I like photopea's UZIP.js library because it is very small and good performance. Are "unzipit" and "zipup" also small and have good performance compared to UZIP.js?

unzipit and zipup are also fast. They also use far far less memory than UZIP.js since they can compress/decompress single files and don't have to decompress an entire zip file. unzipit can also choose to only download the portion of the zip file you care about. UZIP.js can not do this. It requires the entire zip file download first, then it decompresses all entries in memory.

Would you be interested in a PR to "uzip-module"? I have created a typescript port of UZIP.js. Which has proper tree shakablity and built-in type inference, etc. This typescript port was created using GPT-5.4 and code reviewed by Opus 4.6.
And I have fixed some bugs too like

Like mentioned above, the uzip-module is isn't a zip library. It's just a decompression function. As for UZIP.js, this repo has no relation to UZIP.js so if you want to try to contribute your typescript version you should post on that repo.

[mehradotdev]

Understood! thank you for taking your time to answer my queries.
However, I would like to clarify few things you said.

the uzip-module was just pure JavaScript implementation of the "deflate" algorithm. It was not and never has been a "zip" library. It has no concept anything related to zip. It was just the decomprssion part. Hand it some bytes and it decompresses them into more bytes.
...
Like mentioned above, the uzip-module is isn't a zip library. It's just a decompression function.

I think there may be a misunderstanding or maybe I am using the latest version of UZIP.js. Because UZIP.js is not just a decompression function, we can compress files too. My understanding was based on both Photopea’s UZIP.js and uzip-module providing not only raw deflate and inflate helpers, but also ZIP-level parse and encode APIs. That is why I referred to it as a ZIP library, or at least a library that includes ZIP archive parsing and creation in addition to the DEFLATE codec.

It's no longer needed as DecompressionStream provides "deflate" and is built into both the browser and node.

My use case is a little different from the browser and Node cases that benefit from DecompressionStream and CompressionStream. I am using this in a React Native project, where those platform APIs are not something I can assume exist, so a small pure TypeScript port of the UZIP.js ZIP subset is still useful to me. That is the main reason I ported it instead of switching to unzipit or zipup.

unzipit and zipup are also fast. They also use far far less memory than UZIP.js since they can compress/decompress single files and don't have to decompress an entire zip file. unzipit can also choose to only download the portion of the zip file you care about. UZIP.js can not do this. It requires the entire zip file download first, then it decompresses all entries in memory.

I also understand your point about memory behavior. unzipit’s lazy entry access and range-request support are definitely advantages for large or remote ZIPs. My use case is simpler: in-memory ZIP parsing and encoding for app backups, where the small footprint and self-contained implementation are the main benefits.

Thanks again.
tl;dr project is deprecated or at least in maintainance phase.