Hacker News Reader

Comment by perspective1 | Hacker News Reader

Doesn't pass the sniff test. By developer use, npm, for all of its security issues and orphan packages is the most successful package ecosystem of all time.

View on HN

The time risk of NPM (which is the factor considered by this paper) is small though. Security risk is way down most people's considerations.

The paper extrapolates from its survey questions about developer time to loss profitability so I think it's fair to discuss risk as more than just developer time. Even so, the developer time risk of poorly maintained packages is enormous (and not just security-related). Consider the time loss from a security issue in a package you have to replace, fix yourself or wait for someone else to fix. Not to mention the non-time losses. The npm ecosystem has thrived despite this and other risks-- if you want developers to adopt your software, make it interesting, easy to talk-about, frictionless to get started with and shiny. Time is a logical consideration that takes a backseat.

It's well known that success is not a proof of quality. The js ecosystem is an excellent example.

A common quip, but care to elaborate? What is so bad about it.

Yeah, the js ecosystem does a lot of things right that are done poorly in other languages. Compare Yarn to pretty much any package manager besides Cargo, for instance. Another example is that Typescript integration into VSCode is top notch, better than any other language I've used

Does yarn allow reproducible builds?

Yes -- deterministic builds was the primary selling point for many (including myself) when it was first released a few years ago. Npm has since improved somewhat in this regard, but yarn remains the clear leader.

Yarn (and now NPM) allow reproducible builds via a lock file.

What do you mean? By the definition of "risk" in the paper, seems like npm wouldn't be risky.

Questions asked to ascertain risk:

   10 hours are needed to make a module. 

   Making a module is not hobby programming. 

   Conditions  such  as  the  time  needed  to  learn  a  tool  are  the same for each tool. 

   The  tools  are  prediction  tools  such  as  a  static  code  analysis tool.

npm is full of packages (developer tools and libraries in general) popular with developers but that carry enormous risks-- like short support cycles, breaking changes, security issues, packages that themselves depend on packages with similar problems, among other things. You don't have to let a paper define how you evaluate risk, but even if you co-opt their definition of risk as loss profitability, npm's popularity is at odds with "minimizing risk."

Plenty of absolute crap is absurdly popular, that is not much of an argument.

Reply on news.ycombinator.com