added bower.json

[konsumer]

No description provided.

[konsumer]

I think you also will need to bump version to update bower.

[konsumer]

resolves #159

[feross]

What effect does the main field have in bower? Are there toolchains that actually consume it? Most people seem to use bower as a glorified wget, just using it to download packages and then manually referring to the files inside.

Also, bower.json ugh... Why couldn't bower use package.json? The package version will easily get out sync with two files...

[konsumer]

What effect does the main field have in bower?

It is the entry-point for your library. Read more, here.

Are there toolchains that actually consume it?

It can include CSS & JS. There are modules that use it with grunt, gulp, brunch, & others. In the example I gave before it is used by gulp to build the vendor.js & vendor.css file out of the client-side deps. Please have a look at that.

glorified wget, just using it to download packages and then manually referring to the files inside.

Yeah, that's the whole point. I don't care to refer to them manually and rewrite my build system, just to use vendor libraries. I get so bored of endlessly re-packaging, wrapping, and twiddling other people's stuff that I want to use for some lil thing. I try to make my stuff accessible to others, and as useful as I can, even if I don't do things the way people who consume my projects do, if I have the time. If a vendor changes how the entry-point works, or changes anything, I don't have to worry about it, and just be sure my system will keep working without me having to pay that much attention. Not everyone uses CommonJS or browserify for their libs. Not everyone uses anything but window globals. Bower tracks all those differences, and makes it just work, if you're using build stuff that understands it. This might not seem important to you, but for very large projects with a lot of client-side dependencies, it can save a lot of time.

Also, bower.json ugh... Why couldn't bower use package.json? The package version will easily get out sync with two files...

Client-side dependencies are different than server, in lots of subtle and not subtle ways that often affect the work I do. For example, if I deploy on heroku, which reads the server-side deps from package.json, Why should I have to download (many times) a bunch of stupid client-side things to build files that are already checked in as concatted/minified vendor files, and not actually code I directly care about the well-being or maintenance of? Also, as I said, npm does not track CSS, so people would have to manually figure out whenever upstream vendors make changes.

You can automate the package version, or just leave out the bower version (it will pull the version from the latest git tag or package.json.)

You are currently tracking the version in the git tag & package.json, so there is already an argument to add that to your build script: "grab tag version, cram in package.json/bower.json", but really it's optional in bower.json. I think the main reason to explicitly set it separately is to track a locked-in built version. Since you are not using a build system, I included it, because I don't know when you are going to build the minified version.

I'm not really sure what the big deal is, anyway. It's one file, that isn't going to break your stuff. If you don't include the bower.json, someone else (who actually uses your library) will fork it, add the proper bower stuff, and people will use that. Nobody is making you use it. Feel free to not use it, possibly risking having a fork become more popular than your codebase, if the code you have written is useful to others. I don't think I am even going to use webtorrent in my stuff, so I'm not super-clear on why I am taking the time to write a bower.json file, submit a PR, and argue with you about it. I feel like I am trying to help, but again, if it's not helpful to you, no big whoop.

[konsumer]

Also, why the travis fail? Wasn't me (bower is not used tests at all.)