Volo add to a namespace module / auto namespacing

[guybedford]

The main feature request is to allow volo to download directly into a specific path. There are a couple of reasons to do this, which I've described further below. But the basic idea is for:

volo add my/module modules/

To add the library 'my/module' into 'modules' so that all the files are located at 'modules/my/module/...'.

This isn't critical at all, and it's not an urgent feature request. Just trying to get my head around what volo might or might not be able to do in future.

Reason 1: Server & Client code management together

I've been trying to manage my client and server code from the same rough 'lib' folder. This allows for sharing code between the client and server and only maintaining one copy.

If I write some server RequireJS code that I don't want in the public folder, I've been creating a path called '@' and referencing it to '../../server-lib' outside of the public folder.

It would be nice to still be able to use the same main volo package.json to manage adding to this, which the above path addition would allow.

Reason 2: namespacing modules

Imagine a large application being managed through volo. Instead of loading libraries, these libraries could conform to some module format.

If I were to load many modules into the site, it doesn't make sense for these all to be dropped at the root level, as they are not just libraries, but a known module format. Instead I'd like to add all these modules to the 'modules' folder, or whatever I may like.

With the add command at the top, I could then be able to control this.

Even better would be if the modules know that they conform to this format, they could even set this path in their own package.json, so I could skip writing this path entirely.

[jrburke]

The general idea I have been going with is to map closely to the module conventions/path installs used by AMD loaders, as I think it also leads to a clear layout. My first answer would be that code for server and code for client would each have their own package.json files. It is fine to create symlinks (or just duplicate the install) between the two, but that it will not get any fancier than that.

Going to close this for now, as I do not see a clear win here, and I think it clouds how to write out the volo.dependencies section in the package.json file.

[guybedford]

Ok I agree it's not worth complicating the core system here. @jrburke I'm following up mainly to work this stuff out in my own head. No pressure for the response, I understand there are more critical things!

I suppose this splits into two use-cases then:

1) Server-installing RequireJS modules for server-use only in a NodeJS app. The best route forward for this then is to use npm to install a library containing a RequireJS module. I'd probably create a path config to the 'node_modules' folder as something like $server so I can load the server RequireJS dependencies as say $server/myapp/code. The npm module would then have volo dependencies, and a volo add post hook would allow the global dependencies to be installed correctly into the public library folder with volo.

2) Adding volo libraries to subfolders. I think this will become important for large projects. Being able to divide up between a main 'global' folder, and then 'app-specific' folders for dependencies will make management much easier. In this case I think the multiple package.json approach will probably be a good solution here. Perhaps one could allow a way to specify the package.json to Volo. eg: volo add some/module --alt-location, where 'alt-location' would reference 'alt-location.json' in the current folder.

I suppose the above approach for (2) is already supported, simply by 'cd'ing to the right folder and using a volo add. Perhaps that sorts it in most cases.

(2) isn't massively important for me right now, but (1) is something I would start using soon.