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

81–90 of 275 posts

Re: Node.js needs a virtual file system

#81

Post by lacoolj »

charcircuit wrote: post #57
indutny wrote: post #42

Earlier quoted context omitted.

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…

It would be considered (a) since the author would own the copyright on the code.

Owning copyright of something and writing it are very different things

Re: Node.js needs a virtual file system

#82

Post by Normal_gaussian »

chrisweekly wrote: post #63
Dangeranger wrote: post #18

Earlier quoted context omitted.

There are alternative package managers like Yarn that use zip files as a way to store each Node package.[0] [0] https://yarnpkg.com/advanced/pnp-spec#zip-access

Strong recommendation to use PNPM instead of yarn or npm. IME (webdev since 1998) it's the only sane tool for stewardship of an npm dependency graph. See https://pnpm.io/motivation Also, while popularity isn't necessarily a great indicator of quality, a quick comparison shows that the community has decided on pnpm: https://www.npmcharts.com/compare/pnpm,yarn,npm

yarn with zero-installs removes an awful lot of pain present in npm and pnpm. Its practically the whole point of yarn berry.

Firstly - with yarn pnp zero-installs, you don't have to run an `install` every time you switch branch, just in case a dep changed. So much dev time is wasted due to this.

Secondly - "it worked on my machine" is eliminated. CI and deploy use the exact same files - this is particularly important for deeply nested range satisfied dependencies.

Thirdly - packages committed to the repo allows for meaningful retrospectives and automated security reviews. When working in ops, packages changing is hell.

All of this is facilitated by the zip files that the comment you replied to was discussing, that you tangented away from.

The graph you have linked is fundamentally odd. Firstly - there is no good explanation of what it is actually showing. I've had claude spin on it and it reckons its npm download counts. This leads to it being a completely flawed graph! Yarn berry is typically installed either via corepack or bootstrapped via package.json and the system yarn binary. Yarn even saves itself into your repo. pnpm is never (I believe) bundled with the system node, wheras yarn and npm typically are.

Your graph doesn't show what you claim it does.

Re: Node.js needs a virtual file system

#83

Post by Normal_gaussian »

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.

This is quite spammy; you could mitigate it by explaining what you think the "needless suffering" is. Having been using npm, pnpm, and yarn for many years the only benefit I find with pnpm is a little bit of speed when using the cli, but not enough that I notice; I've outlined the major yarn benefit to me 'in a peer comment' (which I didn't realise was you when I answered) https://news.ycombinator.com/item?id=47415660

I expect yarn to have a real competitor sooner rather than later that will replace it; and I do wonder if it is this vfs module that will enable it.

Re: Node.js needs a virtual file system

#84

Post by Normal_gaussian »

zadikian wrote: post #76
chrisweekly wrote: post #64

Earlier quoted context omitted.

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.

This can't be overstated. The main benefit with yarn berry (v4+) is being able to commit the dependencies to the repo - I have yarn based tools that I wrote years ago that just work wheras I frequently find npm and python tools are broken due to version changes. However this benefit comes at a setup cost and a lot more on disk complexity - one off tools are just npm and done.

Re: Node.js needs a virtual file system

#85

Post by lacoolj »

Using Claude for code you use yourself or at your own company internally is one thing, but when you start injecting it into widely-shared projects like this (or, the linux kernel, or Debian, etc) there will always be a lingering feeling of the project being tainted.

Just my opinion, probably not a popular one. But I will be avoiding an upgrade to Node.js after 24.14 for a while if this is becoming an acceptable precedent.

Re: Node.js needs a virtual file system

#86

Post by Deukhoofd »

pier25 wrote: post #55
beart wrote: post #46

Earlier quoted context omitted.

Outside of sqlite, what runtimes natively include database drivers?

Bun, .NET, PHP, Java

For .NET only the old legacy .NET Framework, SqlClient was moved to a separate package with the rewrite (from System.Data.SqlClient to Microsoft.Data.SqlClient). They realized that it was a rather bad idea to have that baked in to your main runtime, as it complicates your updates.

Re: Node.js needs a virtual file system

#88

Post by ronsor »

PaulHoule wrote: post #34
koolba wrote: post #22

Earlier quoted context omitted.

And if you thought malware hiding in a mess of files was bad, just wait till you see it in two layers of container files.

Or worse yet, the performance load of anti-malware software that has to look inside ZIP files. Look, most of us realized around 2004 or so that if you had a choice between Norton and the virus you would pick the virus. In the Windows world we standardized around Defender because there is some bound on how much Defender degrades the performance of your machine which was not the case with competitive antivirus software…

Now we'll have to encrypt the files to prevent the performance hit of antivirus peeking inside.

Oh, wait...

Re: Node.js needs a virtual file system

#89

Post by everlier »

mixologic wrote: post #74
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

We call it a slip slop at work, it's ok to slip some slop if it's "our" slop :-)

Re: Node.js needs a virtual file system

#90

Post by petcat »

_flux wrote: post #19
jitl wrote: post #8

Earlier quoted context omitted.

loud people on twitter are always switching to the new hotness. i personally can't see myself using bun until its reputation for segfaults goes away after a few more years of stabilizing. deno seems neat and has been around for longer, but its node compatibility story is still evolving; i'm also giving it another year before i try it.

Wow, I thought you were exaggerating, but no: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... Open 80, closed 492.

That's basically just Zig, right? Re-invented C but only fixed the syntax, not the problems.
Post reply on HN