The possibility of a component.json spec and package registries

[guybedford]

I was going to post this as a comment under #110, dealing with component.json support for Volo, but thought it was more appropriate for a groups post.

This mostly leads on from @jrburke's comment here - https://github.com/volojs/volo/issues/110#issuecomment-10647675.

Folder-based packages

Folder-based package management is simpler to understand for users and users are more likely to use a simpler process over one they don't understand fully, which in some ways the Volo system may appear to be, for some. Also Bower have shown no interest in implementing the single-file download method (https://github.com/twitter/bower/issues/317).

Consider a jquery plugin, instead of having to write:

require(['jquery-plugin/plugin', 'css!jquery-plugin/plugin'], function(plugin) { ... });

we want to just be able to do:

require(['jquery-plugin']).

One solution here is to automatically generate the base-level 'jquery-plugin.js' file from the component.json. For example, a component.json might show:

{

  "name": "jquery-plugin",

  "version": "0.0.1",

  "main": ["./plugin.js", "./plugin.css"],

  "dependencies": {

    "jquery": "components/jquery#1.9.1"

  }

}

Then a base-level wrapper would be generated of the form:

define(['jquery-plugin/plugin.js', 'css!jquery-plugin/plugin.css'], function(plugin) {

  return plugin;
});

The wrapper has been entirely informed from the "main" property of the component.json.

The component.json could even include shim configuration, for example:

{

  "shim": {

    "exports": "jquery.plugin",

    "deps": ["jquery"]

  }

}

This would translate into the following in the wrapper:

requirejs.config({

  "shim": {

    "jquery-plugin/plugin": {

      "exports": "jquery.plugin",

      "deps": ["jquery"]

    }

  }

});

define(['define(['jquery-plugin/plugin.js', 'css!jquery-plugin/plugin.css'], function(plugin) {

  return plugin;
});

This way, existing repositories can be loaded in an AMD-compatible way, simply by "overriding" their component.json in the registry, just as Volo currently allows overrides.

So the hidden benefit in folder-based packages, is that we are free to create wrappers at the base level which are able to provide a shortcut to the main entry point, while also allowing modular configuration injection and CSS or LESS injection.

This is a major benefit since currently configuration injection can't be handled in a similar way between various AMD implementations.

Dependency ranges and resolution in component.json

The dependencies in component.json now support the name value pairs of `"name": "endpoint#semver range"`. The version management is interesting because it will download the matching versions within the semver range, and alert version conflicts where they happen asking for a resolution. Currently multiple versions are not supported at all in the same repo even under separate names in order to handle version conflict resolution properly. This mostly makes sense on a per-project basis, although in future there may become ways to support this. They are still working at refining this version resolution, but in theory all the conflicts (even with varying names) can be sorted out with a suitable prompt or resolution.

They're not that different really (well to users)

Otherwise, the component.json doesn't feel that far away from volo syntax (at least in terms of dependencies and when using folder-based packages), so it could well be worth working towards a component.json spec like AMD for package management that Volo could also integrate. I think that AMD pushes for a separation of browser and server that is in parallel to the separation of component.json and package.json. I think this is an important distinction because the environments are separate enough that one has to reconsider the implementations quite deeply. So in principle I think the component.json has the best chance of a spec at the moment.

I'm trialling Bower a little more simply to get a feel for it. The codebase still does need some work and there are bugs, but it behaves mostly quite similarly to Volo (in terms of how it comes across to an end user).

Towards an AMD-friendly registry that "just works"

I've been exploring this area because I am looking at building up an AMD-specific registry of modules that "play well together". Jam doesn't seem to solve the version conflict issues, so I am directly tackling these head on. I have a very basic demo up, which I could share offline, and would be quite interested to discuss further to see where these areas are going.

[James Burke]

I have thought about trying to support other package managers, and
technically could support something like a bower: protocol for
bower-stored resources, but building in smarts by default to process
bower.json would result in too much mismatch: the dependency strings
used in bower.json are not the same as dependency strings that volo
uses, and since they assume two different kinds of registries, may
make resolution harder to do.

I also still find the separate bower.json file aesthetically
unpleasant. This is definitely a style thing, but sorry, there it is.
It is goofy that I need to update multiple .json files for versioned
releases, and it results in more file system clutter. In some ways,
with version tags in git, seems silly to stamp the json metadata at
all with my version release. I may depend on a branch for example.

If both volo and bower shared the same registry and dependency string
format, I think it may be more possible to do some adapter work, but I
do not see that happening. And that is the big idea behind volo:
developers already depend on and use github, and it has a business
model behind it, so I feel it should also be a great package manager
registry, and leverage its API (not use it for git clones).

Once a package manager solution drifts from that core idea, then I
think it is different enough that trying to interoperate hurts the
basic idea behind volo. Luckily, with the volojs/repos overrides, if
there is a package that works in bower and not volo, it is easy to
support pretty quickly, without needing the library developer to
change their repository.

James