Bowerfile evaluator

[sheerun]

We can probably re-use bower-rails or bundler code. Here is sample Bowerfile:

source "http://bower.io"

asset "angular"                          # defaults to latest stable
asset "underscore", "~> 2.0"             # ruby convention for versions
asset "cherry", path: "vendor/cherry"    # custom / hacked assets
asset "polyfill", require: "src/geocode" # paths to be included in manifest
asset "lol", github: "organization/lol"  # use custom component from github
asset "oz", git: "git://"                # also, bower-supported protocols

# :group is also available as parameter to asset
group :test, :development do
  asset "karma"
end

I think code above should be evaluated into simple Hash, not a class.

The output of this task is class in format:

class BowerfileEvaluator
  # @param source [String] contents of Bowerfile in Ruby DSL
  # @return [Hash] Bowerfile represented as Hash
  def call(source)
  end
end

Questions:

1. In which context should Bowerfile be evaluated?
2. What should be the normalized Hash format?

[porada]

I think branch field of an asset should also be supported:

asset 'foo', github: 'bar/foo', branch: 'baz'

[sheerun]

Of course. The branch needs to be supported for all version control resources. branch can mean:

1. Branch
2. Tag
3. Commit

[SergeyKishenin]

Agree with interpreting Bowerfile content to Hash. Also I think that we should be able to generate bower.json within BowerfileInterpreter class, not LockfileGenerator, as it's more related to interpreting rather than lockfile generating (just opinion).

Here's our brief for normalized hash format

Not sure about require and path.

Do we need source method? For example, we can support Component but do we really need that right now?

Can branch mean commit and tag (tags can be identical with branches sometimes)? Bundler has three separate keys (ref, tag and branch) for this purposes, so, I think, we should too.

[sheerun]

Another option is BowerjsonGenerator ;)

How about adding groups array to each asset instead?

I thought source means bower registry url (registry [object string] in this document.

I didn't know bundler supports three kind of keys. It's fine for me.

[sheerun]

I though about svn support, and I don't think it's necessary.

It adds more external dependencies and nobody actually uses it in bower.

[sheerun]

Also git prevents by default using the same name for tag and branch. I don't think it will be a problem.

We can use git rev-parse to resolve any reference.

Bower doesn't distinguish between tags/branches/commits. I uses just #something format.

I think normalized hash should normalize branch, ref, etc. to source field for example.

[sheerun]

I think it's good github is normalized to git entry.

[sheerun]

It's worth noticing bower speeds up downloads from github by using archive files that are attached to some tags (https://github.com/bower/bower/blob/master/lib/core/resolvers/GitHubResolver.js#L53).

[SergeyKishenin]

How about adding groups array to each asset instead?

Less nesting within hash, much better, I think.

I think normalized hash should normalize branch, ref, etc. to source field for example.

Agree. Less is more. It's pretty enough to work with the repository.

What is the context you want to use git rev-parse?