dependency order in package.json

[Christoph Dorn]

I am wondering why the order of dependencies is significant in
package.json files.

Christoph

[Kris Kowal]

On Sat, Oct 17, 2009 at 9:20 PM, Christoph Dorn
<christ...@christophdorn.com> wrote:
> I am wondering why the order of dependencies is significant in
> package.json files.

It can but is not likely to be important. However, if it were to be
important, having a consistent topology will make certain overlay bugs
easier to find.

It's probably important at this juncture to be clear that there are
two kinds of dependencies and two kinds of packages in Narwhal's
future. To that end, it might be a good idea to separate the metadata
for these packages into different properties. The point is that
Narwhal presently supports named dependencies, which are installed by
tusk and loaded in dependency topological order at run time because of
the work of the packages module (which sorts the installed packages
based on their dependencies) and the module loader's paths. Let's
call these global-packages. The future Narwhal will additionally
support package-local dependencies, ones that are referenced by a
location (or a catalog (of name to location mappings) location and
name) and a validator, pending CommonJS ratification of such package
management systems.

For local-packages, order does not matter. All packages are
explicitly referenced in the second argument to require, by a unique
identifier mentioned in package.json. There is no overlay or
"depender before dependee" precedence behavior of such modules.

For system-packages, order does matter. The package sorting algorithm
performs a topological, prefix sort of the dependency graph, and
visits nodes in the order they appear in the dependency lists of each
module. So, if module A depends on [B, C, and D], given no other
constraints it will be possible for B to override modules in C because
it appears first in the dependency list. This is not a feature that
we are likely to take advantage of, but having a consistent order of
packages will make it easier to track down which packages might
overlay each other.

Kris Kowal

[Christoph Dorn]

I think it would make sense to provide a separation between the two
notions of dependencies for the two types of packages.

Maybe it could be as simple as:

system-package: {
"dependencies": [
]
}

local-package: {
"dependencies": {
}
}

Where the package loader only gets initialized for local-packages that
map aliases to package locators.

Christoph