5 ms·

NPM still hasn't fixed the "*" package version bug on their end. https://www.youtube.com/watch?v=IzqtWTMFv9Y&t=465 https://www.youtube.com/watch?v=IzqtWTMFv9Y&

• charcircuit 3y ago
  It's intentional and is not a bug. "Fixing" it could cause someone's build to break by someone unpublishing a version.
  • nosefurhairdo 3y ago
    If you use wildcard to specify any version of a dependency you shouldn't be surprised if something breaks.
    • charcircuit 3y ago
      The same can be said about not pinning to a specific version as even some patch releases can break things or change performance characteristics.
      • scubbo 3y ago
        This, to me, is still one of the most astonishing things about the JavaScript ecosystem that everyone just accepts.
        • Aeolun 3y ago
          What is your suggestion for improving it? I can accidentally publish a breaking bug in my patch release, and I might not notice.
          • scubbo 3y ago
            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 https://news.ycombinator.com/item?id=38906936
            • Aeolun 3y ago
              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.
        • nosefurhairdo 3y ago
          Not a big deal, just specify exact dependency versions. Curious how you think other package managers handle this better than npm.
          • scubbo 3y ago
            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!?
            • bakkoting 3y ago
              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 https://github.com/estools/esquery/pull/138
              • scubbo 3y ago
                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!
      • chatmasta 3y ago
        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.
        • nosefurhairdo 3y ago
          > 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 https://docs.npmjs.com/policies/unpublish
  • sneak 3y ago
    Golang’s cryptographically verified module proxy cache solves this problem nicely.
  • spion 3y ago
    A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.
    • charcircuit 3y ago
      If someone has an older version in the lock file this will break the build.
      • spion 3y ago
        Which they can fix by updating the lock file.
  • int_19h 3y ago
    As this package clearly demonstrates, it's a broken design.
    • charcircuit 3y ago
      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.
      • LelouBil 3y ago
        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