Node.js needs a virtual file system

Original Article ↗ Hacker News Discussion ↗

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.