bower/bower.json-spec — pull request #7 by josh (2013-11-12 06:46:14+00:00)
Title: Spec main hash extension mapping

If the main array is to be deprecated #6, I need a replacement for it.

The confusion of the main array comes from the fact that you should only have one type per extension in the array. Making an explicit map of extension to filename reduces the possibility of invalid main definitions.

**extensions not types**

I think “extensions” make more sense over “types” (script, style, font). For one, we’d have to spec all the the types. Bower is about all assets, not about one specific type and the ones we can think of. Maybe you want to package to contain text or data files. We shouldn’t stop you because it doesn’t fit inside a predefined bucket.

`main` is just a path alias.

```
"name": "foo"
"main": {
js: "scripts/bar.js"
css: "styles/bar.css"
}
```

Means alias `foo.js` to `foo/scripts/bar.js` and `foo.css` to `foo/scripts/bar.css`.

Extensions express capabilities to build tools. Some tools can’t handle files that will processing. Require.js for an example will never know what to do with a .coffee file. It needs .js files. It makes sense for it to just use the file of package[‘main’][‘js’]. Other tools like Sprockets are aware of both .css, .scss, .less, etc and can choose the based on which preprocessor the user has available.

```
“main”: {
coffee: “foo.coffee”,
js: “foo.js”
}
```

Seems acceptable to me. Coffeescript aware tools can prefer building from source, while other tools may just pick the compiled version and be fine. This helps Sprocket’s automatic source map generation.