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?
What happens to relative imports?
Node.js needs a virtual file system
41–50 of 275 posts
Re: Node.js needs a virtual file system
#42Taking 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
How exactly does it violate the Developer's Certificate of Origin clause?
The submitted code must adhere to either of (a), (b), (c), and separately a (d) clause of: https://github.com/nodejs/node/blob/main/CONTRIBUTING.md#dev...
If submitter picks (a) they assert that they wrote the code themselves and have right to submit it under project's license. If (b) the code was taken from another place with clear license terms compatible with the project's license. If (c) contribution was written by someone else who asserted (a) or (b) and is submitted without changes.
Since LLM generated output is based on public code, but lacks attribution and the license of the original it is not possible to pick (b). (a) and (c) cannot be picked based on the submitter disclaimer in the PR body.
Re: Node.js needs a virtual file system
#43Earlier 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…
[dead]
Re: Node.js needs a virtual file system
#44Are 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…
I agree about the governance and long-term sustainability points but if you don't see any value in Bun or Deno is probably because (no offense) you are not paying attention.
Re: Node.js needs a virtual file system
#45I'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…
node -e "new Function('console.log(\"hi\")')()"
node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c + 'console.log(exports.say({ text: \"like this\"}))')())"
node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c)()).then(() => console.log(exports.say({ text: 'oh no'})))"Re: Node.js needs a virtual file system
#46The Node team has lost the plot IMO. By far the most critical issue is the over reliance on third party NPM packages for even fundamental needs like connecting to a database.
Outside of sqlite, what runtimes natively include database drivers?
Re: Node.js needs a virtual file system
#47Are people still building new projects on Node.js? I would have thought the ecosystem was moving to deno or bun now
Yes people are using Node.js, most likely the majority.
Re: Node.js needs a virtual file system
#48Would 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.
Would accessing deps directly from a zip really be faster? I'd be a little surprised but not terribly, given that it's readonly on an fs designed for RW. If not, maybe just tar?
Re: Node.js needs a virtual file system
#49The Node team has lost the plot IMO. By far the most critical issue is the over reliance on third party NPM packages for even fundamental needs like connecting to a database.
What would a Node-native database connection layer look like? What other platforms have that? Databases are third party tech, I don’t think it’s unreasonable to use a third party NPM module to connect to them.
Perl has DBI. PHP has PDO.
Re: Node.js needs a virtual file system
#50The Node team has lost the plot IMO. By far the most critical issue is the over reliance on third party NPM packages for even fundamental needs like connecting to a database.
What would a Node-native database connection layer look like? What other platforms have that? Databases are third party tech, I don’t think it’s unreasonable to use a third party NPM module to connect to them.
Most obviously, Java has JDBC. I think .NET has an equivalent. Drivers are needed but they're often first party, coming directly from the DB vendor itself.
Java also has a JIT compiling JS engine that can be sandboxed and given a VFS:
https://www.graalvm.org/latest/security-guide/sandboxing/
N.B. there's a NodeJS compatible mode, but you can't use VFS+sandboxing and NodeJS compatibility together because the NodeJS mode actually uses the real NodeJS codebase, just swapping out V8. For combining it all together you'd want something like https://elide.dev which reimplemented some of the Node APIs on top of the JVM, so it's sandboxable and virtualizable.