Hacker News Reader

Hacker News

Comment by navtoj | Hacker News Reader

Full thread

navtoj

NPM still hasn't fixed the "*" package version bug on their end.

https://www.youtube.com/watch?v=IzqtWTMFv9Y&t=465

View on HN

It's intentional and is not a bug. "Fixing" it could cause someone's build to break by someone unpublishing a version.

If you use wildcard to specify any version of a dependency you shouldn't be surprised if something breaks.

The same can be said about not pinning to a specific version as even some patch releases can break things or change performance characteristics.

This, to me, is still one of the most astonishing things about the JavaScript ecosystem that everyone just accepts.

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 of SemVer. Sure, we cannot 100% trust SemVer (because humans are fallible) - but there is a world of difference between trusting it ~99.9% and 0%. The JavaScript community (from the outside! I could be wrong!) seems to have simply accepted the 0% situation, and all the extra toil that goes along with it, rather than trying to raise the bar of its contributors to be better.

[0] https://news.ycombinator.com/item?id=38906936

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.

Not a big deal, just specify exact dependency versions. Curious how you think other package managers handle this better than npm.

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 are indeed accurate, which is basically equivalent to trusting them to write the correct `version` string (unless you auto-generate the tests, which is an interesting idea but probably impractical).

I'm saying that the fact that it is (apparently) the norm in JavaScript-world that authors will regularly publish breaking changes that are not advertised as such, and that that is just an acceptable everyday uncommentworthy inconvenience, is surprising to me. How do y'all get anything done if you can't even trust SemVer enough to automatically pull in minor/patch updates to dependencies!?

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 performance optimization in a query language [1]. I think these are pretty representative, and not meaningfully worse than the experience in other languages.

[1] https://github.com/estools/esquery/pull/138

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.

Pinning to a specific version doesn't protect against the author unpublishing that version.

The problem with the `*` bug is that it means you can stop anyone from unpublishing future versions of their package by simply creating a package that depends on it with a `*` identifier and publishing that to the registry.

> Pinning to a specific version doesn't protect against the author unpublishing that version.

It does if your project is also in the npm public registry and the package you're dependent on is more than 72 hours old.

https://docs.npmjs.com/policies/unpublish

Golang’s cryptographically verified module proxy cache solves this problem nicely.

A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.

If someone has an older version in the lock file this will break the build.

Which they can fix by updating the lock file.

As this package clearly demonstrates, it's a broken design.

The way unpublishing works is broken. It would be better if unpublish would just hide the version. Then it would not matter if someone unpublished something with dependencies.

That's how crates.io does it with yanked releases.

It's removed from the index, and cargo will only download it using a pre-existing lock file

Reply on news.ycombinator.com