vfs: add ZipProvider - #64915
Conversation
nodejs-github-bot
added
needs-ci
Add a node:vfs provider backed by a node:zlib ZIP archive - a ZipBuffer held in memory or a ZipFile on disk - that exposes the archive's members as a virtual filesystem tree. Directories are recognized both explicitly (a "name/" entry) and implicitly (any entry under "name/"), and a file opened for writing commits its content as a new archive entry when its handle is closed. The provider is read-only unless the backing archive is writable, and offers both asynchronous and synchronous operations. Available as vfs.ZipProvider. Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
b5c818c to
5067a82
Compare
Add close()/closeSync() to ZipProvider and alias them as Symbol.asyncDispose/Symbol.dispose, so a provider can be scoped with `await using` / `using` and release its backing archive at block exit. A ZipFile releases its file descriptor; a ZipBuffer is purely in-memory and has nothing to close, so disposal is a no-op for it. Signed-off-by: Philipp Dunkel <pip@pipobscure.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #64915 +/- ##
==========================================
+ Coverage 90.28% 90.31% +0.03%
==========================================
Files 760 761 +1
Lines 247061 247643 +582
Branches 46592 46789 +197
==========================================
+ Hits 223058 223661 +603
+ Misses 15491 15458 -33
- Partials 8512 8524 +12
🚀 New features to boost your workflow:
|
|
Note: the failing mac-os test seems to be a flakiness issue with that test. I've seen it before and it seems to be entirely unrelated. |
|
@mcollina given you are the VFS man, this one is for you. Note: Next up will be a commandline option --vfs-mount which allows mounting a VFS mount from the CLI for the app to use. This is useful for example to provide an app with an archive of files it can use, like bundled resources. This can be mounted by either mounting a directory (development) or a bundled archive (deployments) Following on from that is a --vfs-load flag that will set the entrypoint to a vfs mounted volume. In the full combination it's possible to have bundled node apps (zip archives) that get loaded. --vfs-mount already allows registering custom vfs-providers (via --import or -r). So what the vfs-provider does (signed code checking, etc...) is up to the user. In the simplest case, you just have an app as a zip archive and it works out of the box. I have all the code already and it's working quite nicely. |
|
I'm doing significant surgery on the vfs machinery in #63653. I need to land that before this. |
Have a look at my branch pipobscure#8 here which does all the module loader work for VFS already. And I've been testing it like crazy. Though from what I see in your PR you're going way deeper, especially the fact that you have an O(1) identification of vfs based modules is a much better solution. So I'm EXTREMELY happy to hold on with this and then rework my other PRs based on your stuff 😄 (starting work based of your solution) Note: It looks like #63653 is entirely orthogonal to this PR as that doesn't alter the Provider surface contract at all. But for sanity sake it's still better to hold this until #63653 is landed and rebase this on that then. |
github-actions
Bot
removed
the
request-ci
4 participants
Add a node:vfs provider backed by a node:zlib ZIP archive - a ZipBuffer
held in memory or a ZipFile on disk - that exposes the archive's members
as a virtual filesystem tree. Directories are recognized both explicitly
(a "name/" entry) and implicitly (any entry under "name/"), and a file
opened for writing commits its content as a new archive entry when its
handle is closed. The provider is read-only unless the backing archive
is writable, and offers both asynchronous and synchronous operations.
Available as vfs.ZipProvider.