Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Everything NPM Package

socket.dev

Post reply on HN
Print view View original

151–155 of 155 posts

Re: The Everything NPM Package

#151

Post by scubbo »

bakkoting wrote: post #147
scubbo wrote: post #142

Earlier quoted context omitted.

I'm not saying that other package managers handle it better - if authors wilfully misrepresent the state of their software, it is indeed not the remit of the package manager to correct them. If you started down that road, you'd probably end up with a library of tests (executed in the package manager's registry) to guarantee a non-breaking change, and at that point you have to trust the package author that the tests a…

It's not common at all. It can happen, but it's very rare. And it's basically never intentional. In my experience the most common cause of breaking changes is accidentally breaking on older versions of the runtime, because the project is only running tests on the last version or two. Aside from that, the only notable example I can think of in the last year was a pretty subtle bug in what was supposed to be a pure per…

Huh. I have got the wrong impression, then, from various blogs/articles which suggest never relying on SemVer because it's regarded as as-good-as-useless. Thanks for setting me straight!

Re: The Everything NPM Package

#152

Post by nosefurhairdo »

scubbo wrote: post #151
bakkoting wrote: post #147

Earlier quoted context omitted.

It's not common at all. It can happen, but it's very rare. And it's basically never intentional. In my experience the most common cause of breaking changes is accidentally breaking on older versions of the runtime, because the project is only running tests on the last version or two. Aside from that, the only notable example I can think of in the last year was a pretty subtle bug in what was supposed to be a pure per…

Huh. I have got the wrong impression, then, from various blogs/articles which suggest never relying on SemVer because it's regarded as as-good-as-useless. Thanks for setting me straight!

And on my team we pin exact versions and use semver to inform the level of scrutiny when we manually update packages. Probably hasn't prevented any issues, but it helps folks sleep at night knowing our code doesn't change unless we tell it to.

Re: The Everything NPM Package

#153

Post by Aeolun »

scubbo wrote: post #143
Aeolun wrote: post #68

Earlier quoted context omitted.

What is your suggestion for improving it? I can accidentally publish a breaking bug in my patch release, and I might not notice.

I believe there is no process or tool that could reliably do so (see sibling comment[0]). Indeed, at some point you need to trust an author that what they are publishing is what they say they are publishing, and authors being fallible means that mistakes _might_ slip by. What I'm surprised by is the apparent cultural norm that this is just a regular everyday occurrence which entirely erodes any faith in the meaning o…

I don’t think this is quite true. I can expect semver to work correctly in about 70% of all instances (working with JS/TS every day).

Biggest issues are authors that keep their libraries at 0.x forever (every minor chance can be a breaking one) and the ones that release a new major version every other week.

The times I do a minor update and something breaks are generally regarded as a bug by authors too.

Re: The Everything NPM Package

#154

Post by KomoD »

StressedDev wrote: post #100
6510 wrote: post #95

Earlier quoted context omitted.

You design a language for a purpose (which could be anything) you develop and mature it's features to better fit it's use case. html, a crappy defective xml implementation refuses to grow up, js, while great for little html tweaks is not adopting any of the useful features found in popular npm packages. It was actively developed for 2 weeks. Ripping off it's head (nodejs) gave us a poor sailor jargon ~ but without th…

HTML came before XML. Also, how is HTML crappy when it is used by millions of web sites and is one of the most successful technologies in the past 35 years? Does this mean it is perfect? No. Is it "crappy"? Nope. Also, while JavaScript had a rushed development cycle, it has grown over the past 20-30 years and you can clearly write some great programs in it. Also, it has some very good features. My favorite is you can…

> Also, how is HTML crappy when it is used by millions of web sites and is one of the most successful technologies in the past 35 years?

That does not mean it's good.

Lead paint was widely used in the Europe and Americas for a very long time, doesn't mean it was good

Re: The Everything NPM Package

#155

Post by Bjartr »

SahAssar wrote: post #38
Bjartr wrote: post #35

Earlier quoted context omitted.

IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.

So could you list those problems?

One issue is npm will allow arbitrary code to execute as part of an install script for a package, which allows a class of attacks that aren't possible in the maven world.
Post reply on HN