Oh, you're right, that would work. I wonder, how many packages you encounter that do not match shasum (== republished)?
About locking in general: unfortunately, too often a patch version is better than an original dependency, but someone writes a module, locks down a dependency and very rarely updates it. This is the issue I encountered very often, and that's exactly why I hate locking packages at all, preferring open ranges like ">= 1.2.3". It's often better to have a new version with possible bugs than to be stuck with a legacy one for a year.
23.12.2013, 10:04, "Sean McArthur" <[email protected]>:
--We do check the shasum, using https://npmjs.org/package/lockdown
On Dec 22, 2013 9:49 PM, "Alex Kocharin" <[email protected]> wrote:You made it sound like locking will guarantee that no bugs will be introduced. You don't hardcode sha1sum, do you? :-)23.12.2013, 08:42, "Sean McArthur" <[email protected]>:There are good reasons to lock a dependency at a version. I'd love to accept all patch versions, but unfortunately too often a patch version introduces a new bug, or changes the API, and breaks my apps/libs. If I know my app works with a lib at 1.2.3, then my workmates better be able to npm install and get the same working version.
On Dec 22, 2013 6:13 PM, "Mikeal Rogers" <[email protected]> wrote:For reference:9768 packages lock 24538 dependencies in 57515 different versions of those packages.https://gist.github.com/mikeal/8090801 (will work as soon as I can publish npmetrics, currently getting allocation errors).-MikealOn Dec 22, 2013, at 5:46PM, Mikeal Rogers <[email protected]> wrote:On Dec 22, 2013, at 4:45PM, Alex Kocharin <[email protected]> wrote:23.12.2013, 04:36, "Mikeal Rogers" <[email protected]>:* allow aggressive caching, reducing the cost of the npm registry and making npm use faster for most use casesthis isn't an issue. the cache control can, and must, be proactively invalidated on _changes from the database for document urls anyway, it's trivial to do the same for tarball changes. it can literally cache forever so long as it responds to pro-active invlaidation.HTTP caches know nothing about _changes feed.NPM can't sit behind a standard HTTP cache on a TTL because a document change must take effect immediately. The work going in to putting it behind a cache is using a _changes listener to invalidate the cache.* change behaviour only for version-locked dependencies when that (and only that) specific patch is unpublishedi'm not disagreeing with you but when you say things like "change in behavior" you're sort of sugar coating the fact that packages will fail to install at a greater rate than they do now. this "change in behavior" is not trivial, there is no notice sent to someone when their package can no longer resolve a dependency, it will usually require someone to see a failed install, report an issue, and the maintainer to intervene. the only way to avoid this is to never version lock your dependencies which we know people don't do and that there are tens of thousands of packages in npm today with some number of version locked deps.Patching npm to treat "1.2.3" like "~1.2.3" as a fallback would solve this task. I know it's ugly, but it's no less ugly than unpublishing-republishing practice, because you essentially doing the same thing.Any changes to npm client take ~2 years to distribute enough that you can deprecate the behavior in an old one.// alex--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/fDs5-Wl3I8c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/fDs5-Wl3I8c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
