Finer grained control over module usage

[natevw]

I don't think having a single list of "modules" will scale well. A CouchApp may or may not want to use a given module in any of at least three places:

• server-side show/list/update functions, i.e. targeting ddoc.lib
• view functions, i.e. ddoc.views.lib
• client-side pages, i.e. ddoc._attachments

For example, I might want modularized versions of Fermata and d3 attached for use on the client side but don't need copies in the design document itself. Or perhaps I do also want to use d3 in my show/list functions in which case I'll also need jsdom there (but not sent to the browser).

It would also be nice to define more than one module for the client-side. Not saying that a page would include more than one (probably simpler AND more optimal to have one JS bundle per page), but saying that different types of pages might need different modules.

Even more ideally, I could specify specific versions for each usage. I may want to keep a view's map/reduce function locked to a particular version to avoid rebuilding indexes, while tracking a more up-to-date version for the browser...

Essentially I'm imagining going from the current:

"modules": ["app.js", "lib"],
"modules_attachment": true

to something more like:

"modules": {
    ".lib": {"thing1": null, "thing2": "2.0"},
    ".views.lib": {"thing2": "1.4.2"},
    "._attachments.main_modules": {"thing1": null, "foo": null, "bar": null},
    "._attachments.admin_modules": {"thing1": null, "baz": null}
}

Are these reasonable requests for the intended scope and use cases of this package?

[natevw]

(Perhaps this would be better as a mailinglist discussion or split into a few separate tickets. I'd be happy to refactor as appropriate, lemme know.)

[caolan]

This looks interesting: https://github.com/substack/wreq

By combining something like this with the current approach perhaps we might only pull down the modules actually used to the client-side, without having to manage them separately from server-side modules (just add all of them as individual attachments and as ddoc properties)... the extra http requests to fetch each module might actually hinder load times though.