Bowerfile.lock generation

[sheerun]

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:

1. JSON format is fast, extensible, and easy to parse, we don't need custom format
2. The converter for Rails Assets already uses output of bower install to generate gem
3. The bower.json format is insufficient as we need for example resolved dependencies

Here is sample output: https://gist.github.com/sheerun/9378451

Almost all fields are needed though we can do few simplifications:

1. canonicalDir is not relevant as we choose where component is installed
2. dependencies hash for each component could be simplified to array of strings
3. nrDependants is probably redundant

Output of this task is class in following format:

class LockfileGenerator
  # @param bower_json [Hash] bower.json from BowerjsonGenerator
  # @return [Hash] the generated Bowerfile.lock
  def call(bower_json)
  end
end

Questions:

1. Should we perform mentioned simplifications or leave bower install output as is?
2. How to handle single asset updates?

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 with generate_bower_json and pass it to bower update <asset>. Only relevant asset will be updated then.

[sheerun]

I'm not sure if call should accept/return String/Hash.

[SergeyKishenin]

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)

[sheerun]

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.

[sheerun]

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.