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). -Mikeal On 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 cases >>> >>> this 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 unpublished >>> >>> i'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 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.
