Best way to deal with a packaging strategy?

[DamonOehlman]

Hey Guys,

Starting to take a good look at volo with the view to using it since it has been built with goals that align very closely to my own (using github where possible, etc). One thing I am wondering though is how to best reconcile my approach to building a multiple distributions for a library, rather than having just one file that complies to just one of the module approaches (e.g. none, CommonJS, AMD).

I'm really committed to trying to write code once and once only, and while the UMDjs approach provides support for that in a very simple sense it all breaks down once dependencies get involved.

I've started writing more on the topic here, which explains my current approach:

http://reusable-javascript.readthedocs.org/en/latest/packaging.html

I think volo definitely has the capacity to work in with the way I build libraries, but just wondered whether this is something that you are interested in having integrated into the tool (I'm happy to do the work) or not.

Anyway, love what you've done with the place - keep up the great work :)

Cheers,
Damon.

[DamonOehlman]

I see that some of this information is covered in the wiki here:

https://github.com/volojs/volo/wiki/add-dependency-rules#wiki-detectamd

I guess given that volo has a preference to using AMD, a definition like this in the package.json file should be enough to get volo running...

[jrburke]

There are a few forces at play that tend to not want to allow selecting a particular module style for download with volo, but I am curious what your take is on it:

1. The code using different module systems are likely targeting different JS envs and therefore will use different package manager/repos. For instance, if using node, the code will be published to npm. volo is focused on working with front-end libraries. That leaves browser globals and AMD as possible formats for volo. At that point, I would probably just encourage folks to use a UMD wrapper, or just use globals, and then use something like requirejs shim config if the project is AMD-based (or provide the AMD info in a package.json field and have volo auto-wrap).

2. I thought ECMAScript Harmony, ES.next was due to be wrapped up by early 2013. If they work out a solid module format, then hopefully this wrapping becomes less important. There will still be legacy code concerns, code that needs to run in harmony and non-harmony browsers, so maybe it would still need wrapping in some cases.

So I suppose maybe a limited form of wrapping could just be supported natively by volo, or shim config stamping. I would tends toward that instead of say, allowing something like volo.url to take an object/hash:

"volo": {
  "url": {
    "amd": "path/to/lib.amd.js",
    "globals": "path/to/globals.amd.js"
  }
}

My experience with library owners so far seem to be either they are OK with doing a UMD type of thing, or they do not want to talk about AMD at all. Maybe it would not be so bad if to support AMD they could specify some details in the package.json and then allow volo to do the wrapping though.

Anyway, just some rambling first thoughts.

[DamonOehlman]

Definitely agree that only AMD and globals need to be accommodated, and I think your suggested configuration information would work perfectly and is something that I could auto-generate during the build step with Interleave too.

Also, I think you are absolutely right with library authors completely disregarding AMD or only accommodating it through implementation of a UMD wrapper. I guess one of my underlying opinions on the stuff I have been building with Interleave and supporting tools, is to try and accommodate building libraries that work with multiple module patterns because well that's the point of JS isn't it. It should be up to the author to decide which platforms it's supported on but the users of the library.

Anyway, I'm going to keep working with volo and potentially make some more significant contributions to the project as like I said it matches my goals.

Thanks for having the vision to create volo, using github repos, tagging, etc as controls for projects. I definitely don't think we need another NPM to deal with client side dependencies, just a well thought out approach that makes use of existing quality resources.

[jrburke]

Great to hear. OK, let's keep this ticket open to make sure we explore what kind of metadata would be needed in a package.json or maybe an amd.json to allow auto-wrapping on install. Maybe it is something too where the project can specify amd.shim = true in the package.json and then volo would create shim config block in the project instead of wrapping the source files.

I am going to focus on the near term of getting some things fixed for 0.2.3, but we can continue this discussion and get it worked out for a future release.

[wilmoore]

+1 on amd.shim = true