Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js needs a virtual file system

blog.platformatic.dev

Post reply on HN
Print view View original

71–80 of 275 posts

Re: Node.js needs a virtual file system

#71

Post by dfabulich »

TheRealPomax wrote: post #17
wccrawford wrote: post #13

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 mi…

But then you go "hang on, doesn't ESM exist?" and you realize that argument 4 isn't even true. You can literally do what this argument says you can't, by creating a blob instead of "writing a temp file" and then importing that using the same dynamic import we've had available since 2020.

A virtual filesystem makes it possible for the ESM you import to statically import other files in the virtual filesystem, which isn't possible by just dynamically importing a blob. Anything your blob module imports has to be updated to dynamically import its dependencies via blobs.

Re: Node.js needs a virtual file system

#72

Post by zadikian »

dzogchen wrote: post #9
petcat wrote: post #3

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

I don't really understand what the value proposition of Bun and Deno is. And I see huge problems with their governance and long-term sustainability. Node.js on the other hand is not owned or controlled by one entity. It is not beholden to the whims of investors or a large corporation. I have contributed to Node.js in the past and I was really impressed by its rock-solid governance model and processes. I think this an…

Note that Bun was recently acquired by Anthropic.

Re: Node.js needs a virtual file system

#73

Post by digikata »

goalieca wrote: post #62
digikata wrote: post #53

Earlier quoted context omitted.

Large PRs could follow the practices that the Linux kernel dev lists follow. Sometimes large subsystem changes could be carried separately for a while by the submitter for testing and maintenance before being accepted in theory, reviewed, and if ready, then merged. While the large code changes were maintained, they were often split up into a set of semantically meaningful commits for purposes of review and maintenanc…

> With AI blowing up the line counts on PRs, Well, the process you’re describing is mature and intentionally slows things down. The LLM push has almost the opposite philosophy. Everyone talks about going faster and no one believes it is about higher quality.

Go slow to go fast. Breaking up the PR this way also allows later humans and AI alike to understand the codebase. Slowing down the PR process with standards lets the project move faster overall.

If there is some bug that slips by review, having the PR broken down semantically allows quicker analysis and recovery later for one case. Even if you have AI reviewing new Node.js releases for if you want to take in the new version - the commit log will be more analyzable by the AI with semantic commits.

Treating the code as throwaway is valid in a few small contexts, but that is not the case for PRs going into maintained projects like Node.js.

Re: Node.js needs a virtual file system

#74

Post by mixologic »

indutny wrote: post #29

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 in 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

Worth noting that mcollina is a member of the Node.js Technical Steering Committee

Re: Node.js needs a virtual file system

#75

Post by Normal_gaussian »

mohsen1 wrote: post #59
Normal_gaussian wrote: post #52

Earlier quoted context omitted.

The way to do this today is to do it outside of node. Using an overlay fs with the overlay being a ramfs. You can even chroot into it if you can't scope the paths you need to be just downstream from some directory. Or, just use docker.

making that work cross platform is pure pain

yes and no. Waiting 40mins for every test run is pure pain, platform specific ramfs type mounting is quite scriptable. Yes some devs might need to install a dependency, but its not a complex script.

Re: Node.js needs a virtual file system

#76

Post by zadikian »

chrisweekly wrote: post #64
Normal_gaussian wrote: post #32

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 wai…

Strong rec to choose PNPM over yarn. I just posted this in a peer comment: https://news.ycombinator.com/item?id=47415173 Not spamming, not affiliated, just trying to help others avoid so much needless suffering.

I just use npm because I like to stay as vanilla as possible. Glad that alternatives exist though.

Re: Node.js needs a virtual file system

#77

Post by iainmerrick »

austin-cheney wrote: post #10

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 exceedingl…

Why would you want a language enhancement for that, rather than just writing it in JS code? (or perhaps WASM)

Re: Node.js needs a virtual file system

#78

Post by epolanski »

indutny wrote: post #36
epolanski wrote: post #31

Earlier quoted context omitted.

Do as I say, not as I do. On a more serious note, I think that this will be thoroughly reviewed before it gets merged and Node has an entire security team that overviews these.

As someone who was a part of the aforementioned security team I'm not sure I'd be interested in reviewing such volume of machine generated code, expecting trap at every corner. The implicit assumption that I observed at many OSS projects I've been involved with is that first time contributions are rarely accepted if they are too large in volume, and "core contributor" designation exists to signal "I put effort into t…

For free, you can decide to do what you want, if it's your job, it's a bit different and you may have to do so, especially considering Collina, is one of the largest contributors of the project and member of the technical committee.

Re: Node.js needs a virtual file system

#79

Post by duped »

austin-cheney wrote: post #10

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 exceedingl…

> As an aside I think JavaScript would benefit from an in-memory database.

isn't that just global state, or do you mean you want that to be persistent?

Post reply on HN