3 ms·

>The author hasn't made a secret of his versioning policy. No one is going to see that unless they go looking for it though >you shouldn't have used "~", "^"

>The author hasn't made a secret of his versioning policy. No one is going to see that unless they go looking for it though >you shouldn't have used "~", "^" That is how the npm ecosystem works, and in any case the issue arose from dependencies that in turn depended on underscore and thus are not under my direct control. > Anyway, with a decent test suite, surely a modicum of (automated) testing has already identified the pinning that should take place? My particular issue is in a new project I could not install several dependencies as npm downloaded the newest compatible version which was supposedly 1.7.0 - the only way to fix this is to manually create a lock file. >you depend for free. True, and I'm tremendously grateful for all the work that has gone into it and it would be a massive shame if that work was for nothing if a continued disregard for semver forces people to switch to lodash.

jessaustin 12y ago
...dependencies that in turn depended on underscore... Do you imagine that the maintainers of all these dependencies are going to catch any fraction of the hell that jashkenas seems to be catching for this? It's just as much their fault as it is his. Why don't they pin and test?
- abritishguy 12y ago
  Because that is not the convention in the ecosystem - npm mandates the use of semver - if you follow it this can't happen. If you do what you say and pin it down to an exact version then you would have to release an update every week consisting of just a version bump.
  - jessaustin 12y ago
    Don't stop there: think it all the way through! Breaking changes lead to version bump releases, whether the module follows semver or not. https://news.ycombinator.com/item?id=8244888 https://news.ycombinator.com/item?id=8244888 Do you mean to imply that breaking-change frequency should stay below some particular maximum value? That argument is completely unrelated to the use or disuse of semver.
goldfeld 12y ago
For nothing? So something that is used only temporarily is worthless? If you didn't have to write boilerplate or your own functional library because underscore existed at some point, you had a net gain in productivity and was able to release your own code faster, regardless of whether you eventually end up switching.

jessaustin 12y ago

...dependencies that in turn depended on underscore... Do you imagine that the maintainers of all these dependencies are going to catch any fraction of the hell that jashkenas seems to be catching for this? It's just as much their fault as it is his. Why don't they pin and test?

abritishguy 12y ago
Because that is not the convention in the ecosystem - npm mandates the use of semver - if you follow it this can't happen. If you do what you say and pin it down to an exact version then you would have to release an update every week consisting of just a version bump.
- jessaustin 12y ago
  Don't stop there: think it all the way through! Breaking changes lead to version bump releases, whether the module follows semver or not. https://news.ycombinator.com/item?id=8244888 https://news.ycombinator.com/item?id=8244888 Do you mean to imply that breaking-change frequency should stay below some particular maximum value? That argument is completely unrelated to the use or disuse of semver.

goldfeld 12y ago

For nothing? So something that is used only temporarily is worthless? If you didn't have to write boilerplate or your own functional library because underscore existed at some point, you had a net gain in productivity and was able to release your own code faster, regardless of whether you eventually end up switching.