Virtual File System for Node.js by mcollina · Pull Request #61478 · nodejs/node
Matteo Collina's virtual file system PR for Node.js introduces a first-class node:vfs module with a provider-based architecture that lets you mount in-memory, Single Executable Application, or custom filesystems alongside the real filesystem. It intercepts 164+ fs and module-loader integration points to make require() and standard fs APIs work seamlessly with virtual files, includes overlay mode for surgical mocking, and integrates with the test runner.
Script: Haiku 4 Voice: OpenAI TTS
Transcript
Justy Okay, Cody, I just read through this Node.js virtual filesystem PR and I'm actually kind of blown away by the scope.
Cody Yeah.
Justy Matteo Collina just dropped 133 commits that add a whole node:vfs module. I want to know if this is real or if it's one of those things that sounds good until you actually try to integrate it.
Cody Give me the one-liner first.
Justy Virtual filesystem you can mount at a prefix—like /virtual or /sea—and it hooks into fs, fs.promises, and the module loader so require() just works. In-memory files, bundled assets, custom backends, whatever you want.
Cody Hm.
Justy How's your week been, by the way? I feel like I haven't caught up with you in forever.
Cody Long. I was debugging a deployment issue on Friday that turned out to be a symlink resolution problem in a container, of all things. Spent four hours staring at permission logs. But yeah, this PR—how many interception points are we talking?
Justy One hundred sixty-four. That's the actual number. They say it in the FAQ.
Cody That's not a number, that's a threat.
Justy Right? But here's the thing—the design is actually clever. It's not a Proxy or a dispatch table. They use per-function handlers, and when no VFS is active, it's literally a single null-check.
Cody Okay, that's smart. vfsState.handlers is null, you skip the whole thing.
Justy Exactly. Zero overhead when the VFS isn't mounted. Virtual file descriptors start at ten thousand so there's no collision with OS FDs. It's not sloppy.
Cody What about the module loader? That's the sticky part.
Justy They wrap the loader functions—stat, readFile, realpath, all that—and install VFS-aware versions on first mount. Both CommonJS and ESM go through the same wrappers, so require() and import work from virtual files without special handling.
Cody That's... actually solid. But a hundred sixty-four integration points is still a massive surface to maintain. What's the PR size?
Justy Eleven thousand tests, nine thousand lines of code, one thousand lines of docs. And they used Claude to generate a bunch of it.
Cody Oh wow.
Justy Yeah. But they say they reviewed everything themselves. The FAQ is honest about it—no one's tackled this before because it's just huge. AI made it feasible.
Cody So the real question is: does anyone actually need this in core, or does it belong in userland?
Justy That's what I want to talk through. The test runner integration alone is worth it—t.mock.fs() creates an overlay VFS that auto-restores. You can mock specific files and let everything else fall through to the real filesystem.
Cody Right, right. Overlay mode.
Justy And Single Executable Applications—assets are bundled into the binary and automatically mounted at /sea. You read config, templates, whatever, with standard fs calls. No custom APIs.
Cody That's the SEA case. What else?
Justy In-memory workflows. You create a VFS, mount it, write some files, require() them, unmount. The whole thing is synchronous if you want it to be. That unlocks a whole class of use case—code generation, embedding, testing—that's awkward right now.
Cody But here's my concern: the PR says they could put it behind a flag. The high-risk parts—the integration points—still get exercised. So why merge it into core at all? Why not ship it as a userland module first, prove it works, then decide?
Justy Because the module loader hooks can't work from userland. You need to intercept the loader before CommonJS and ESM start resolving. That's a core-only problem.
Cody Fair. Okay, I'm less skeptical now. But the maintenance burden is real. Every new fs API has to add a hook. Every fs bug might need a VFS audit.
Justy Yeah, but they've got one hundred sixty-four integration points already. The pattern is established. It's not like they're inventing something new each time.
Cody True. So if this ships, it's a win for testing, bundling, and embedded workflows. The tradeoff is surface area and ongoing review.
Justy And the fact that a chunk of it was AI-generated. That's going to be a conversation, for sure.
Cody Yep. But they were transparent about it, which is better than pretending they hand-wrote eleven thousand lines of tests.
Justy Right. I think this actually ships, Cody. It solves real problems and the design is clean.