shrinkwrap doesn't really work well in practice, it almost never makes sense to not pin versions directly. Even "bug fixes" introduce non-deterministic behaviour in an application so if you're not uber rigorous at the QA level in stage it's pretty likely to screw you over
On Thursday, 24 October 2013 22:08:23 UTC-7, Alex Kocharin wrote: > > > 25.10.2013, 07:48, "Stuart P. Bentley" <[email protected]<javascript:> > >: > > The way I see it, the "dependencies" hash in package.json right now is > pulling double-duty. In some cases (where the value of a dependencies field > is a semver), it's there to describe *generally* what module versions it > expects to be compatible with. In other cases (when the value of a field is > a URL), it's there to describe the *exact* version of a module it's used > with. > > > Dependencies should specify an open version range (unless there is a > really good reason to do otherwise). > > If someone wants an exact version, he should probably learn about > shrinkwrap. > > > > > This mixed-purpose approach has a few shortcomings: for one, packages > outside the canonical registry can't specify version ranges. > > > Why? I don't have any issues with that when I use version ranges for > packages in my private registry. > > > > > - Use a different hash (let's call it "wants") that handles > future-looking package usage, where each package (by > node_modules/package.json/require() name) > > > > > Don't add any more hashes. Pleeeease. Just modify a dependency hash to be > a hash of hashes like that: > > dependencies: { > package1: { > version: '>= 0.1.2-something', > isDevDependency: true, > isOptional: true, > wants: 'more cookies', > }, > package2: { > .... > } > } > > Something along these lines. Current situation with multiple, but similar > hashes (optionalDependencies, peerDependencies, devDependencies, etc.) > ain't extensible and very much suck. > > > > What does the community think? If npm wouldn't be willing to go ahead with > something like this, any interest in producing some kind of fork? > > > Almost definitely yes. This feature alone hardly worth a fork, but there > are many things that are wrong with npm, so forks can be quite useful here. > Frankly speaking, I'd even be interested in remaking it from scratch > because some things are just too hard to fix. > > > -- -- 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.
