Are people still building new projects on Node.js? I would have thought the ecosystem was moving to deno or bun now

Would be nice if node packages could be packed up in ZIP files so to avoid the security/metadata tax for small file access on Windows.

>Let me be honest: a PR that size would normally take months of full-time work. This one happened because I built it with Claude Code.

The node.js codebase and standard library has a very high standard of quality, hope that doesn't get washed out by sloppy AI-generated code.

OTOH, Matteo is an excellent engineer and the community owes a lot to him. So I guess the code is solid :).

Most of the 4 justifications mentioned sound like mitigations of otherwise bad design decisions. JavaScript in the browser went down this path for the longest time where new standards were introduced only to solve for stupid people instead of actually introducing new capabilities that were otherwise unachievable.

I do see some original benefits to a VFS though, bad application decisions aside, but they are exceedingly minor.

As an aside I think JavaScript would benefit from an in-memory database. This would be more of language enhancement than a Node.js enhancement. Imagine the extended application capabilities of an object/array store native to the language that takes queries using JS logic to return one or more objects/records. No SQL language and no third party databases for stuff that you don't want to keep in offline storage on a disk.

I'm not convinced that allowing Node to import "code generated at runtime" is actually a good thing. I think it should have to go through the hoops to get loaded, for security reasons.

I like the idea of it mocking the file system for tests, but I feel like that should probably be part of the test suite, not Node.

The example towards the end that stores data in a sqlite provider and then saves it as a JSON file is mind-boggling to me. Especially for a system that's supposed to be about not saving to the disk. Perhaps it's just a bad example, but I'm really trying to figure out how this isn't just adding complexity.

Is node::vfs the new solution for JupyterLite filesystems?

From https://github.com/jupyterlite/jupyterlite/issues/949#issuec... :

> Ideally, the virtual filesystem of JupyterLite would be shared with the one from the virtual terminal.

emscripten-core/emscripten > "New File System Implementation": https://github.com/emscripten-core/emscripten/issues/15041#i... :

> [ BrowserFS, isomorphic-git/lightningfs, ]

pyodide/pyodide: "Native file system API" #738: https://github.com/pyodide/pyodide/issues/738 re: [Chrome,] Filesystem API :

> jupyterlab-git [should work with the same VFS as Jupyter kernels and Terminals]

pyodide/pyodide: "ENH Add API for mounting native file system" #2987: https://github.com/pyodide/pyodide/pull/2987

    You can’t import or require() a module
    that only exists in memory.

You can convert it into a data url and import that, can't you?

I'm not convinced this needs to be in core Node, but being able to have serverless functions access a file system without providing storage would definitely have some use cases. Had some fun with video processing recently that this would be perfect for.

Taking the question of whether this would be a useful addition to Node.js core or aside, it must be noted that this 19k LoC PR was mostly generated by Claude Code and manually reviewed by the submitter which is my opinion is against the spirit of the project and directly violates the terms of Developer's Certificate of Origin set in the project's CONTRIBUTING.md

yarn pnp is currently broken on Node v25.7+;

- https://github.com/yarnpkg/berry/issues/7065

- https://github.com/nodejs/node/issues/62012

This is because yarn patches fs in order to introduce virtual file path resolution of modules in the yarn cache (which are zips), which is quite brittle and was broken by a seemingly unrelated change in 25.7.

The discussion in issue 62012 is notable - it was suggested yarn just wait for vfs to land. This is interesting to me in two ways: firstly, the node team seems quite happy for non-trivial amounts of the ecosystem to just be broken, and suggests relying on what I'm assuming will be an experimental API when it does land; secondly, it implies a lot of confidence that this feature will land before LTS.

I could see something like this being useful if it could be passed to workers to replace any fs access inside the worker.