zlib, vfs: add ZIP archive support and an archive vfs provider

[pipobscure]

Summary

node:zlib — ZIP archive support (ZipEntry, ZipFile, ZipBuffer)

• Read, create, and mutate ZIP archives entirely in pure JS, reusing the existing deflate/zstd bindings (no new native code).
• ZipEntry: reads and builds individual archive members, supporting store, deflate, and zstd compression methods. Includes a streaming variant (createStream()/contentStream()) for incremental production/consumption without buffering a whole member in memory.
• ZipBuffer: an in-memory, always-writable view over an archive buffer. Entries can be added, replaced, or deleted; toBuffer() serializes the current live set into a fresh archive with a new central directory.
• ZipFile: a disk-backed archive, read-only by default and writable via { writable: true }. Adding an entry appends it where the central directory used to be and rewrites the central directory in place; deleting rewrites the central directory only (no growth). compact() streams a fresh archive with dead entries removed, without touching the still-open file.
• Every method has a synchronous *Sync counterpart, documented as event-loop-blocking (mirroring node:fs's own wording). An internal busy-flag guard prevents a sync call from racing an in-flight async mutation on the same ZipFile.
• New error codes: ERR_ZIP_ENTRY_CORRUPT, ERR_ZIP_ENTRY_NOT_FOUND, ERR_ZIP_ENTRY_TOO_LARGE, ERR_ZIP_INVALID_ARCHIVE, ERR_ZIP_NOT_WRITABLE, ERR_ZIP_UNSUPPORTED_FEATURE.
• zlib.getMaxZipContentSize()/setMaxZipContentSize() bound decompressed entry size by default, to guard against zip-bomb-style entries.
• Encrypted entries and unsupported compression methods are rejected consistently across content(), contentSync(), and contentStream().

node:vfs — ArchiveProvider

• Mounts a ZipBuffer or ZipFile as a virtual file system. provider.readonly reflects the underlying archive's own writability.
• Directories are recognized both explicitly (an entry ending in /) and implicitly (any entry prefixed "<dir>/").
• Since a ZIP member can't be edited or read in place, writes are buffered in memory and only committed as a new archive entry when the handle is closed.
• Full synchronous method parity (openSync, statSync, readdirSync, readFileSync/writeFileSync, mkdirSync, rmdirSync, unlinkSync, renameSync, ...), backed by ZipBuffer/ZipFile's own sync surface and documented as event-loop-blocking.

Test plan

• test/parallel/test-zlib-zip*.js, test/pummel/test-zlib-zip-slow.js — ZipEntry/ZipFile/ZipBuffer creation, round-tripping, writability, sync parity, zstd, fuzzing, hardening (encrypted entries, unsupported methods, truncated/garbage archives), zip64 boundaries, metadata, and property-based tests.
• test/parallel/test-vfs-archive-provider.js — construction validation, stat/readdir over explicit and implicit directories, full async and sync CRUD against both a ZipBuffer and a ZipFile source, read-only enforcement (EROFS).
• Full node:zlib/node:vfs parallel suite run against a local build (171 tests) to confirm no regressions.

P.S.: my CLA should be on file and I wrote this myself so COO is declared

[codecov]

Codecov Report

❌ Patch coverage is 95.82899% with 120 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.31%. Comparing base (4ee2117) to head (2a56a15).

Files with missing lines	Patch %	Lines
lib/internal/zip.js	95.22%	102 Missing and 9 partials ⚠️
lib/internal/vfs/providers/archive.js	98.28%	7 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64339      +/-   ##
==========================================
+ Coverage   90.23%   90.31%   +0.07%     
==========================================
  Files         741      743       +2     
  Lines      240979   243856    +2877     
  Branches    45401    46181     +780     
==========================================
+ Hits       217449   220236    +2787     
- Misses      15112    15172      +60     
- Partials     8418     8448      +30     

Files with missing lines	Coverage Δ
lib/internal/errors.js	97.71% <100.00%> (+<0.01%)	⬆️
lib/vfs.js	100.00% <100.00%> (ø)
lib/zlib.js	98.36% <100.00%> (+0.02%)	⬆️
lib/internal/vfs/providers/archive.js	98.28% <98.28%> (ø)
lib/internal/zip.js	95.22% <95.22%> (ø)

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pipobscure]

Just to show where this is coming from and where I'm going with this.

pipobscure#3 is a follow on to handle resolving inside a vfs/archive. And based on both of those this is how one could nicely build SEA apps and/or distribute bundled apps.

[bakkot]

See also #45651

[jasnell]

ZipProvider might be better. We might have other forms of "Archive"` later.

[pipobscure]

It’s agnostic to the algorithm. So as along at the API shape stays the same it should work with others as well. But I take note and have no objections to changing it.

[pipobscure]

See also #45651

Thanks @bakkot !!!

I think the time has come for it on the one hand, and on the other I added some „motivation“ links earlier. Here some more detail:

Based on this, we can modify the loader to directly load from an archive. If we do that, we get application bundles. pipobscure#3

Which can then in turn be used to easily create SEA apps. https://github.com/pipobscure/experimental-sea

So the world had changed enough that it‘s worth proposing again.