Open sheerun opened 10 years ago
I'm not sure if call should accept/return String/Hash.
Yes, the simplest is the best, so we can easily remove redundant fields.
Updating a single asset using bower update
seems to be the easiest one. We can leave it for the first time and go on thinking about more autonomous solution (I thought that the main idea was to be completely independent from the bower)
The main idea is to be independent from bower in production :)
In development we won't avoid forwarding dependency resolution to bower. At least for now.
I extracted bower.json generation to #3 and changed output type to Hash. I don't think we should handle JSON strings anywhere in gem directly. The Hash/Mash representation is OK.
The reason is easy testing.
Basic idea is to use bower to create Bowerfile.lock with resolved dependenies. Bowerfile.lock is used in production to download and convert all relevant assets (no bower required).
The format of Bowerfile.lock should be similar to the output of
bower install -f -q
:bower install
to generate gembower.json
format is insufficient as we need for example resolved dependenciesHere is sample output: https://gist.github.com/sheerun/9378451
Almost all fields are needed though we can do few simplifications:
canonicalDir
is not relevant as we choose where component is installeddependencies
hash for each component could be simplified to array of stringsnrDependants
is probably redundantOutput of this task is class in following format:
Questions:
bower install
output as is?As far as I know bower uses bower.json to handle single asset updates (it builds targets list from
bower.json
and**/.bower.json
in current directory, modifies one or more targets and run resolving procedure (https://github.com/bower/bower/blob/master/lib/core/Project.js#L443)That means we should be able to generate
bower.json
withgenerate_bower_json
and pass it tobower update <asset>
. Only relevant asset will be updated then.