Node.js needs a virtual file system

Node vs Deno/Bun and ecosystem direction

• Some ask whether new projects should move to Deno or Bun; responses say Node is still the majority choice.
• Bun is criticized for segfaults and Zig-based runtime maturity; Deno praised for sandboxing but its Node compatibility is seen as incomplete.
• Node’s multi‑stakeholder governance and perceived long‑term sustainability are cited as major advantages vs. company‑controlled runtimes.

Motivations for a Node virtual file system (VFS)

• Proposed benefits: bundling apps as single executables, faster tests by avoiding disk IO, better multi‑tenant sandboxing, and loading code that exists only in memory.
• Some embedded/SEA users want to ship JS inside binaries without writing to disk, or have safer plugin models.
• Others note similarities to Go’s io.FS/embed, Java JARs, Yarn’s zip storage, and browser‑side VFS work (JupyterLite, pyodide, etc.).

Critiques and alternative approaches

• Several argue this duplicates OS features (ramdisks, OverlayFS, Docker, FUSE, snapshots) and increases Node complexity.
• Some say Node should expose a pluggable “fs core” interface instead of baking in a full VFS.
• Others see many justifications as mitigations for questionable design decisions or niche cases.
• Security concerns: importing runtime‑generated code may be too easy; some prefer explicit “hoops.”

Testing, performance, and packaging

• Windows NTFS + node_modules file explosion is a recurring pain point; zip‑style packaging is seen as attractive but raises malware/antivirus overhead worries.
• Yarn PnP already patches fs to read from zip archives; it recently broke on Node 25.7+, prompting suggestions to “wait for vfs,” which some view as risky given ecosystem breakage.
• Some want a simple runtime flag to swap the entire fs with an in‑memory backend for massive test speedups.

AI‑generated 19k‑line VFS PR

• The PR was largely authored with an LLM and then manually reviewed; reactions are sharply divided.
• Concerns:
  • Violating the spirit or letter of the project’s DCO, given unclear copyright and training data.
  • Reviewer burden and motivation to scrutinize large machine‑generated patches “trap at every corner.”
  • Long‑term maintainability, hidden bugs, and security issues in foundational code.
• Defenses:
  • Legal counsel reportedly okayed AI‑assisted contributions under the DCO.
  • AI used mainly for boilerplate (multiple fs variants, tests, docs); humans still design and review.
  • Some argue refusing AI will slow Node relative to competitors; others counter that runtimes should prioritize stability over iteration speed.

Security, sandboxing, and dynamic code loading

• Debate over whether Node’s new permission model counts as real sandboxing; some say it’s only a “seat belt” and can be bypassed by malicious code, whereas Deno’s model is considered stricter.
• Critics note that code can already be loaded from memory via Function, blobs, or loader hooks, questioning “you can’t import from memory” as a justification.
• A VFS would help ESM modules that need static imports of other virtual files, including workers and native .node modules, where blob‑based workarounds fall short.

Dependencies, package managers, and database drivers

• Yarn (especially PnP + zero‑installs) vs pnpm vs npm is debated: pnpm is praised for sane dependency graphs; Yarn is praised for reproducibility and committing deps; some stick with plain npm.
• One thread argues Node over‑relies on third‑party packages even for basics like database access; other ecosystems (.NET, Java, PHP, Perl) are cited as having more standardized database layers.
• Counterpoint: most DBs are third‑party tech; perhaps vendors or runtimes like Bun (with built‑in drivers) should address this, not Node core.