On Thursday, October 24, 2013 10:08:23 PM 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.
>
Did you read the rest of the proposal? Take a look at the section that
starts "Loose semver ranges used to be a Big Important Deal". tl;dr: in
Node, open version ranges only apply to updates, and there is a really good
reason to shrinkwrap (you can't be sure about those updates before they're
released, and once they are you should explicitly confirm you can use them).
>
> 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.
>
Because running and requiring a private registry is mega impractical,
especially if you want to publish modules that are usable outside your
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: {
> ....
> }
> }
>
>
Changing the read semantics of existing fields in package.json would break
everything that currently reads package.json. That's untenable. That's why
I'm talking about introducing a new hash:it doesn't require any changes to
be compatible with what already exists.
Current situation with multiple, but similar hashes
(optionalDependencies, peerDependencies, devDependencies, etc.) ain't
extensible and very much suck.
I agree that the optionalDependencies and devDependencies solutions suck-
if you read the proposal, you'll notice that the "wants" hash allows an
extensible alternative to those (one that doesn't break the compatibility
with older systems).
The important thing here is backwards compatibility. Adding a future-proof
hash keeps compatibility and utility of the existing hashes, in a way that
still works with what's already out there. You don't just break 45,000
packages because they weren't perfect.
>
>
> 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.
>
>
>
npm works pretty well right now and still has tons of traction with module
developers. Gently modifying it to work with what people are already doing
it is a much more feasible approach than saying "drop everything and come
do my completely different thing".
--
--
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.
