On Friday, October 25, 2013 8:05:54 PM UTC-7, Isaac Schlueter wrote: > On Thu, Oct 24, 2013 at 8:48 PM, Stuart P. Bentley > <[email protected] <javascript:>> 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. > > A separate registry which, at that point, becomes your new canonical registry. The current design of package.json is such that, even if it doesn't have to be npmjs.org, the package can still only use one registry, and that registry is what I mean when I refer to "the registry".
(In general, I think this idea of using package.json specifications that depend on the external configuration of npm and a live personal server are a *really bad* answer to registry-based shortcomings, but that's a separate discussion for another thread.) > > 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. > > Okay, I wasn't aware anybody was actually doing this (I've never seen it used). The change I'm proposing would make dedupe easier, too, since right now dedupe isn't possible for anything outside of the registry (where you can't specify ranges). > > > "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? > The reason I'm talking about tightening up "dependencies" is because that makes its purpose a little less conflict-y with the new field I'm proposing for tracking one-level-higher package descriptions. If the proposal was "use dependencies exactly the same way but also use this slightly different thing that's a little more versatile at the cost of more complexity", it would be almost completely redundant and insipid. Tightening up the intention of "dependencies" reduces the redundancy, and it adds a nice backwards-compatible benefit that's currently missing for Node packages. The idea is that `npm install` is a command that installs modules directly from paths specified in "dependencies": with "dependencies" always referring to a specific version, `npm install` always installs the same modules it did when the package was defined. > 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". > I know that changing the semantics of the "dependencies" field is out of the question, which is why I am talking about using a different field (the "wants" field) for the different-semantics info. All this would do is make the dependencies field more accurate and simple without using the secondary semver info that, due to the broadness of the specifications "dependencies" already accepts, you couldn't depend on being present anyway. > > 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. > > That's a matter of the tools/ecosystem, though (and Google is better at searching for / discovering JS packages than npm anyway). What this change means is that non-registry packages are no longer second-class *inside of package.json*. > > > 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. > Specifying every package in "dependencies" with an explicit location is already valid right now, right? How would anything that depends on "dependencies" working exactly like it does be broken by dependencies working exactly like it does, but more conservatively? > > > `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? > Dedupe using git, tagged releases within a semver range prior to the branch tip, etc. Anywhere you want something newer, but not the latest. For example, say that I know that my code isn't going to work with asdf 3.x, but I want it to update from asdf 2.4.x to the compatible minor release asdf 2.6.x. > 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. > Refetching a volatile path kind of defeats the purpose of versioning. Are there really a lot of people out there using the external state of the world as their package definition? How do you `git bisect` that? Time travel? (My proposal doesn't make specifying volatile paths impossible, but it makes declaring it look as anemic as it should.) > 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`? > It means packages can't be broken during a rebuild because the semver range was broad enough to pull in a "bugfix" that introduced a regression (which, if anybody thinks this is a high-falutin' hypothetical scenario, is something that has broken http://stuartpb.com/profiles *right now*). Updating with `npm i asdf --save` and `npm update` here are two different things, if I understand correctly (`npm update` updates the package to the latest allowed by a specified semver, and `npm i asdf --save` changes the semver to specify the latest version). Both are useful (for the above example where I want something newer but not the latest, I'd want `npm update asdf` and not `npm install 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.
