volo add with amd does not save amd for future reinstall
Opened this issue · 4 comments
To reproduce, run:
volo add -amd https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-rc.3/angular.js depends=jquery=jQuery exports=angular
Contents of package.json:
{
"volo": {
"dependencies": {
"angular": "https://ajax.googleapis.com/ajax/libs/angularjs/1.3.0-rc.3/angular.js"
}
}
}
Expected behaviour:
rm angular.js
volo install
# angular.js should be amdified
Thanks for the great tool that is volo!
Will think about it for 0.4.0, but in the meantime, I updated https://github.com/volojs/repos to include angular/angular
with the URL overrides and amd info, so now if you do:
volo add angular/angular/1.3.0
It should do the right thing, even on reinstall.
Great idea, specially for automation (CI) where volo install
would be used to set the desired structure for building the app, specially because the build will generally fail on interactive commands.
I would be great to have the depends
and exports
information embedded into package.json
as well.
one question @jrburke, I saw that for angular, the amd.json
was created in order to establish the amd information. Is the amd.json
referenced somewhere with more information or is it just a temporary workaround?
I found out that by using requirejs shim config options achieves that perfectly, working around the current issue where there would be no need to re-define that in volo as well.
That being said, it could work like the below, while these settings could be used for both runtime and optimisation with r.js without the need of creating multiple files through mainConfigFile
option as well.
requirejs.config({
shim: {
angular: {
deps: ['jquery'],
exports: 'angular'
}
}
});
However, it would still be handy to be able to perform that straight from volo I guess. Specially when building volo re-usable packages that depend on other libraries that need this shim.
I find shims very awkward to use when dealing with multiple projects. I want to simply copy/init my deps and be done with it. Specifying them in two places is not optimal.