On Thu, Oct 24, 2013 at 8:48 PM, Stuart P. Bentley <[email protected]> wrote: > 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.
Fair point. > This mixed-purpose approach has a few shortcomings: for one, packages > outside the canonical registry can't specify version ranges. By "canonical registry" do you mean npmjs.org? Because you definitely can use ranges with a separate registry. > What's worse, > any discussion of these shortcomings inevitably devolves into a > back-and-forth over the utility of the registry (with arguments over > everything from naming techniques, to implied triviality, to diplomatic > protocol). Indeed. > Loose semver ranges used to be a Big Important Deal, back in the packaging > flatlands of Python and Ruby. In those worlds, every module in use had to > agree to share one particular version of any module- every module had to > accommodate any potentially outdated code. Where a dependency was coming > from didn't matter, but the ways it would be acceptable to come was. > > In Node, however, packages, once installed, will never see their > dependencies versions any older than the latest they were written (unless > they're peerDependencies). The one purpose of ranges is to allow potential > optimizations and bugfixes from any future revisions of dependencies, > without having to explicitly declare it. At this point, keeping that > looseness, as a core attribute of the runtime, is a weakness, one that's > overshadowing the increasingly pressing issue of where that package is > located. You're neglecting the dedupe case. That's very relevant for some use cases, especially for frontend packages. > "dependencies" is tightened up for repository packages (bringing them to the > specificity non-repository packages are already subject to). New packages > can't rely on ranges that can become invalid (due to either a too-loose > semver requirement or a breaking change in a minor version). A guaranteed > shrinkwrapped dependencies field means you know *exactly* what revisions the > package was developed against at time of publication. What's the point of doing that? Just to have the metadata for packages that aren't bundling their deps? Changing the semantics of the "dependencies" field is completely out of the question. If there's a strong case for tracking that info, and a field that's not already in use in the wild, then I'd consider doing it as something other than "dependencies". > Packages outside the registry are no longer second-class citizens. Well, yeah, they sort of are. Users can't search for them, install them by name, etc. > Calling "npm install" or "npm update" with a package.json that uses semver > ranges (or tagless git URLs) automatically shrinkwraps "dependencies" and > converts the existing "dependencies" values to the equivalent "wants". Never gonna happen, sorry. Way too much stuff depends on dependencies working exactly like it does. > `npm update` would have to read the "wants" field, and would need additions > to find available semver tags in non-registry locations (like tags in a Git > repo). What cases is that relevant for? npm update already re-fetches from git and urls. If you specify a url, then you want to update, well, ok, put a new thing at that url. Same with git, just specify a branch, and it'll always pull the latest from that branch. > For developers, the listed semvers would need to be loosened/tightened > appropriately, and `npm update` would be required to update a code's > dependencies. (Good.) Why is this good? What's wrong with updating using `npm i asdf --save`? -- -- 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.
