> Fuzzy dependency versions (^2.0.0 and alike) should not be allowed in final versions. Multiple times I have witnessed npm modifying the package lock file of a project when running npm install after a fresh clone, downloading newer versions of transitive dependencies than those specified in the lock file
That sounds like a bug or mis-design in npm, if it's not respecting versions in the lockfile, when no top-level dependency requirements have changed. Isn't the lockfile supposed to... lock?
If you don't allow dependencies to express ranged requirements on their dependencies (your transitive/indirect dependencies), it means that whenever an indirect/transitive dependency releases a security fix, you need to wait on anything in the dependency tree that refers to the fixed thing to release an update, and hope it releases an update without breaking changes for your app.
Yeah, that statement was rather surprising. The lockfile does lock versions. The only time NPM will modify the lockfile on install is if you install a new dependency or modify the package file to require a package version range that contradicts what's currently in the lockfile.
So while it is possible that npm would modify the lockfile after a fresh clone, the only way that could happen would be if the package.json file was already out of sync with the lockfile on the branch you checked out.
You should be using `npm ci` or `yarn --pure-lockfile` instead of npm install. Of course that can't be the default because of "legacy". That's the burden of a Javascript dev, carrying around lots of knowledge about what you shouldn't use.
> Of course that can't be the default because of "legacy".
Then why did they change the default behavior to use fuzzy matching? Because someone decided it was the best decision. It isn't about breaking changes, it's about someone's arbitrary decisions and those decisions are arguable.
sorry the title was too long, I had to cut a word!
edit: I also had no idea about the shooting yesterday I tend to stay away from the news as it is far too politicized these days and normally just leaves me angry/unhappy
Honest question: When is it appropriate to talk about this stuff? I see this often: "We are speaking about <event> too soon after it happened, we need to let the families <grieve|move on|have space>." It seems like one <event> happens, we can't talk about it, then a new one happens and the cycle goes on, never stopping to sit down and discuss how we keep ending up here.
It's appropriate _now_ to discuss the shooting; but I'm not really sure it's ever going to be appropriate to turn the Onion's blistering satire into a punchline here.
What the Onion did is a valid, necessary, mildly amusing, but incredibly pointed and powerful criticism of the gun problem in America.
What this article is doing is making that criticism into a punchline in and of itself. That is what is disrespectful.
I wrote two comments[0][1] on Reddit about this, but I think there's a bit of JS-bashing happening here since a lot of the issues described here are relevant for many other package managers other than NPM.
There are notable problems with how modern software is built with deep dependency graphs and the potential supply chain attacks that are possible because of this, but none of that is exclusive to NPM. NPM has a preference for small single purpose packages and JS is massively popular which might make this problem worse, but it's a problem for a lot more communities and languages than JS/NPM.
The problems mentioned are relevant to other package managers and languages, but they’re obvious problems that other package managers solved 20+ years ago.
Even the ones that haven’t solved the underlying problems have done substantially better jobs mitigating them than NPM. (pip and docker hub are the only counterexamples that come to mind).
> The problems mentioned are relevant to other package managers and languages, but they’re obvious problems that other package managers solved 20+ years ago.
Which package mangers and how? The ones I can think of[0] and are familiar with suffer from the same or very similar problems[1].
0: Bundler, Cargo, CocoaPods, Composer, Pip(to a lesser extent)
1: Name squatting, typo squatting, malicious versions via compromised accounts/publishing credentials, compromises to the delivery infrastructure(AFAIK NPM protects against this with the integrity field in package-json.lock)
More to the point, if a package maintainer turns malicious, as it appears was the case here, none of the changes this article is suggesting will help at all.
2FA means nothing if you can't trust the person publishing the package.
Compare and contrast with a modern design, like Nix. npm's conception of packages as named, owned, versioned, published, etc. is all window dressing around an inherently-faulty set of assumptions.
> "A lot of effort has been put by individuals to promote new ideas. Many of those innovators get nothing out of their effort but the fame of their library. The TC39 would gain the power to render an existing effort mute and thereby ruining a life's work. What do you intend to do to prevent private agendas resulting into half-baked and/or derivative solutions that might do more harm to the ecosystem than good?"
I don't want to swear on HN, so I'll just say .. wow. So there are elements of the community who want to keep the deficiencies there so they can get micro-fame for filling them? People want to feel important by maintaining left-pad?
(also I think they meant moot rather than mute, but hey; also, this is software, we don't really respect idea precedence and any work may be rendered moot by the work of others at almost any time as technology shifts.)
There are better things to be wow'd over than a random encounter with an online idiot. It's the most used language in the world, there are plenty of idiots to be found.
Except you're not really solving the right problem.
The problem is not that the standard library is bad (It could be shite, it could be gold, it doesn't really matter). The problem is that regardless of what's in your "standard" library, you will have a VERY long tail of users interacting with your code in a user agent that just doesn't support it. Period.
So I think you can rephrase this whole conversation as not "make a better standard library!" but instead as "how do we bootstrap a better standard library into user agents that haven't been updated in 10 years?"
In which case suddenly NPM/Babel/Webpack start to make a lot of sense.
I'm not finding this article substantive, it appears to be trying to pick a fight for its own sake rather than adding anything new or interesting to the broader discussion around package security.
I haven't seen data that suggests that NPM malware is more common than most other package managers when you adjust for relative size and rate of new packages.
It's not clear to me how any of the suggested changes that the author proposes would have stopped the last attack, since it likely involved a package author deliberately sabotaging their own package.
The author ignores any of the technical considerations as to why standard libraries are kept small in Javascript. It's an oversimplification of an extremely complicated topic. Javascript has concerns that languages like Python, Ruby, and PHP don't -- namely backwards compatibility and the inability to correct bad decisions once they've been made.
The article is filled with claims that just don't make sense or are outright wrong (unpublishing packages is already not allowed on NPM).
I want to assume the author does actually have experience on the web, and they're not just mad that Javascript/Node exists -- so from a charitable interpretation, this article could have done more to dig into why the recent NPM scare is fundamentally different from similar situations that have popped up recently in, say, Ruby Gems[0].
Hot take: The Onion's version of this article is a blistering, sobering satire. The verbatim re-posting for different mass shootings [1] makes even more powerful. This article, however, is inappropriate and offensive because it takes that quite necessary critique and turns it into a joke.
The Onion wasn't joking with their article. Satire isn't just about humor (though it sometimes leverages it). This author entirely missed the point of what the Onion did and should really re-think if this is something they want to be associated with.
It's entirely appropriate to talk about gun control and gun reform, all the time - even (and especially) immediately after a mass shooting. It's never appropriate to turn the mass shooting tragedy into a punchline for to get more clicks on your article.
Is there actually a decent alternative to JS for front end stuff? Another part of the solution to this language turning into the blob monster from the end of Akira surely has to be making those with an interest in the language's success less complacent.
I mean, why argue for _not_ having a standard library?
Yeah, it was just a parody of the articles The Onion regularly releases regarding another topic and to be honest I didn't quite expect my post to take off the way it did.
I'm also sorry I posted it on Medium, which I personally dislike, but since Medium is frequented by many JS devs it seemed the ideal place to put that joke.
That sounds like a bug or mis-design in npm, if it's not respecting versions in the lockfile, when no top-level dependency requirements have changed. Isn't the lockfile supposed to... lock?
If you don't allow dependencies to express ranged requirements on their dependencies (your transitive/indirect dependencies), it means that whenever an indirect/transitive dependency releases a security fix, you need to wait on anything in the dependency tree that refers to the fixed thing to release an update, and hope it releases an update without breaking changes for your app.
That doesn't sound like where you want to be.