Is npm Enough? Why Startups Are Coming After This JavaScript Package Registry (redmonk.com) 21
The JavaScript package world is heating up as startups attempt to challenge npm's long-standing dominance. While npm remains the backbone of JavaScript dependency management, Deno's JSR and vlt's vsr have entered the scene with impressive backing and even more impressive leadership -- JSR comes from Node.js creator Ryan Dahl, while npm's own creator Isaac Schlueter is behind vsr. Neither aims to completely replace npm, instead building compatible layers that promise better developer experiences.
Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation.
Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation.
"Problem: There are now 28 competing standards." (Score:2)
Re: (Score:3)
It's both a celebration and a destruction of open source as a concept.
You can publish any sort of tool for others to use in their projects easily, and on the other side you can find a tool for almost anything you need. But the idea of just changing the code you fetch to suit your needs has become an extremely difficult problem to solve. You can't just go edit the code to fix it for your case and push it to your team's repo, and send a patch to the owner if you think it helps.
No. Now you gotta go up to th
Re: (Score:3)
>You can't just go edit the code to fix it for your case and push it to your team's repo, and send a patch to the owner if you think it helps.
Actually, you can, and I've had to do it (sadly more than once). You can:
* patch the code in the `node_modules` on your server (and be careful about not letting `npm i` overwrite the fix)
* copy the code (from node_modules) into your project, modify it, and change all your imports to reference it there
* you can do a true fork (of the original project), modify it, b
Re: (Score:2)
That strategy only holds until you need to install a security update for one of the other packages, then, sorry, you're fucked, the dependency tree is ruined.
A question (Score:3)
How on earth did anyone ever write code before the advent of these always connected library collections?
Re: (Score:1)
You downloaded the libraries manually. As the repositories became more popular, and there was more cross-library code reuse, it required downloading more and more libraries individually. So the package manager was born.
Re: (Score:3)
/dev/random
the predecessor to CoPilot
Re: (Score:2)
Back then, you had the MST3K fan motto: Keep circulating the tapes. Tapes with all kinds of useful code would be passed along and copied. That's what User Groups were for.
Re: (Score:2)
Punchcards, of course.
Re: (Score:2)
You find some FTP site and you untar the thing you depend on. It's not uncommon to do something similar in C or C++ to this day. It's a huge pain but that's the way it was and still is in some cases.
Re: (Score:2)
Often, you just found code somewhere and then typed it in yourself. But everyone hated doing that, so as soon as it became cost-effective the books and magazines would come with floppy disks (or later CD-ROMs).
I don't remember having disks in magazines by 1988 (though they might have come in some coding books?), so I think you either paid for a boxed library (with disks inside), or you bought the magazines/books and typed their code in yourself. And really, I don't think there were a ton of libraries back
Re:A question (Score:4, Informative)
I've developed C and C++ for decades and the answer to that was you downloaded some random distribution of the thing you depended on and then you lashed everything together with string. Because different projects tended to be built in different ways and you had to coral the dependencies to build and link with your own compilation flags and link settings and it was all a massive pain in the ass. Consequently when you got things working you were averse to upgrade or change things because of the inherent time cost. As time went on, software got more complex so the need to use external libs for UI, crypto, web, database etc. just gets more and more involved. Things like CMake made life easier but it was still unpleasant. Then conan or vcpkg appeared up to add dependency management which made things slightly easier.
But bottom line, life in languages without package management is bullshit. Be glad if your language toolchain has package management. That isn't the end of concerns of course. Packages come with their own risks in terms of security or breaking changes, so nothing is set it and forget it. Modern package managers attempt to mitigate some of the risks with audits, security checks etc. but there is still a risk that a rogue package 3 dependencies deep from your layer has been compromised. The "best of both worlds" would be toolchains that have secure repositories for convenience but allow devs to lock things down and use local snapshots or git hashes as deps if they prefer.
waste (Score:4, Interesting)
Re: (Score:3)
Why does anybody use such a broken ecosystem when alternatives exist?
Is it just because nobody wants to write their own libraries anymore?
Re: waste (Score:2)
Anymore? Nobody ever wanted to, they had to.
Every language... (Score:5, Funny)
Has the package manager it deserves. It is a reflection of the language's community.
NPM is:
More JS package managers won't fix anything. All the problems stem from what the JS community considers to be a package, and that in JS world DRY actually means desiccated.
No other language's community would sincerely entertain the notion of an is-even package.
XKCD as predictor of real life (Score:1)
NPM needs to improve (Score:3)
The NPM site needs to improve and do a bit in terms of quality control. My items:
- Preventing publishing packages with no linked website or README.md
- Prevent duplicate packages which are just referring to the same GitHub repo (currently they don't seem to care)
Probably... (Score:3)