I don't use shrinkwrap, instead I copy an entire folder from staging to
production currently, and it works reasonably well.
Anyway, if a library has a certain bug in version X, and it is fixed in
version X+1, you have basically the same chance to have an some kind of an
issue with it. Existing bug can screw you over or a bugfix can screw you
over. I've seen both cases, but first one usually the most painful.
Imagine that I use a library X that depend on Y that depend on Z. Library Z
contains a bug which affects library X indirectly. If all maintainers
specified an open version range, I just need to submit a bugfix to library
Z, and all things will work after an update. If all maintainers pinned down
their versions, I'd need to contact Z maintainer to apply a bug fix, then
I'd need to contact Y maintainer to update dependencies, then I'd need to
contact X maintainer to update. Usually some of the libraries in the chain
are barely maintained, so I'll get my bug fixed in a couple of months at
least.
Anyway, there're three schools of thought:
1. specify completely open ranges ('*', '>= 1.0', etc.)
2. pin down major/minor numbers ('1.2.x', '>=1 <2', etc.)
3. specify exact version ('1.2.3')
I strongly prefer first in my libraries, I'm reasonably fine with second
one, but third choice is nothing but trouble.
On Saturday, October 26, 2013 9:00:36 AM UTC+4, tjholowaychuk wrote:
>
> 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]>:
>>
>> 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.
