On Saturday, October 26, 2013 4:26:43 AM UTC+4, Stuart P. Bentley wrote: > > On Thursday, October 24, 2013 10:08:23 PM UTC-7, Alex Kocharin wrote: >> >> 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. > My private registry currently eats 40 megabytes of memory and 57 megabytes of diskspace, including 33 lines of config file. Sounds impractical yeah.
> > 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. > "dependencies": "Object|String" is backward-compatible in regard to existing packages. I thought it's obvious. > 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". > > If npm was working well, we weren't be here discussing this right now. ;) -- -- 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.
