> no human wants to hand-write: implementing every fs method variant (sync, callback, promises), wiring up test coverage
That’s so dehumanizing, I would happily write such code.
Node.js needs a virtual file system
191–200 of 275 posts
Re: Node.js needs a virtual file system
#192Separate the valid critiques on other comments, Go's io.FS interface is really nice for making these sorts of things. Is there something like this in Node already? (with base implementations like host and in memory)
Another thread about Edge.js has some similar concepts that might be applicable? They're not 1:1 the same but it involves Sandboxing https://news.ycombinator.com/item?id=47417398
Re: Node.js needs a virtual file system
#193Earlier quoted context omitted.
Not sure if you are intentionally misrepresenting (a), but here is the full text (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
That seems exclusive of LLMs, as the user didn't create the contribution, the LLM did.
Orthogonal to? Irrespective of the use of?
Re: Node.js needs a virtual file system
#194Separate the valid critiques on other comments, Go's io.FS interface is really nice for making these sorts of things. Is there something like this in Node already? (with base implementations like host and in memory)
Another thread about Edge.js has some similar concepts that might be applicable? They're not 1:1 the same but it involves Sandboxing https://news.ycombinator.com/item?id=47417398
I would put virtual or filesystem abstractions in a different category than sandboxing, which puts restrictions over the virtual or native implementations.
Re: Node.js needs a virtual file system
#195Taking 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
Fully disagree with this take. Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives. Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions: I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.…
> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.
That sort of statement might also be sarcasm in another context: I personally use AI a lot, but also recognize that there are a lot of projects out there that are suffering from low quality slop pull requests, devs that kinda sign out and don't care much about the actual code as long as it appears to be running, alongside most LLMs struggling a lot with longer term maintenance if not carefully managed. So I guess it depends a lot on how AI is used and how much ideological opposition to that there is. In a really testable codebase it could actually work out pretty well, though.
Re: Node.js needs a virtual file system
#196Earlier quoted context omitted.
Another thread about Edge.js has some similar concepts that might be applicable? They're not 1:1 the same but it involves Sandboxing https://news.ycombinator.com/item?id=47417398
I would put virtual or filesystem abstractions in a different category than sandboxing, which puts restrictions over the virtual or native implementations.
I mean that's a fair distinction. There's definitely some overlap depending on needs though.
Re: Node.js needs a virtual file system
#197Earlier quoted context omitted.
When npm decided to have per-project node_modules (rather than shared like ruby and others) and human readable configs and library files I think the goal was to be a developer friendly and highly configurable, which it is. And package.json became a lot more than that as a result, it’s been a great system IMO. Combined with a hackable IDE like Atom (Pulsar) made with the same tech it’s a pretty great dev exp for web d…
It’s one thing or another. Python had shared packages for a long time and those are fine up to a point but circa 2017 I was working at a place where we had data scientists making models using different versions of Tensorflow and stuff and venv’s are essential to that. We were building unusually complex systems and having worse problems than other people but if you do enough development you will have trouble with shar…
I still prefer shared packages because it incentivizes developer to have a stable API. And you always have an option to manipulate the path variables and have projects (java) and virtual env (python). Cargo and NPM always seems to be straight from Alice’s dreams (Lewis Caroll).
Re: Node.js needs a virtual file system
#198Earlier 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…
Nobody wants to review AI-generated code (unless we are paid for doing so). Open source is fun, that's why people do it for free... adding AI to the mix is just insulting to some, and boring to others. Like, why on earth would I spent hours reviewing your PR that you/Claude took 5 minutes to write? I couldn't care less if it improves (best case scenario) my open source codebase, I simply don't enjoy the imbalance.
> Like, why on earth would I spent hours reviewing your PR that you/Claude took 5 minutes to write?
If the PR does what it says it does, why does it actually matter if it took 2 weeks or 2 minutes to put together, given that it's the equivalent level of quality on review?
Re: Node.js needs a virtual file system
#199I'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…
Not a Lisp fan?
Re: Node.js needs a virtual file system
#200[dead]