Specification

[sindresorhus]

Related to #53 and #46

For the component.json to have any future it's needs a spec. It doesn't have to be verbose, just what properties it should support and how those should be validated.

15 March 2013
Draft specification - https://docs.google.com/document/d/1APq7oA9tNao1UYWyOm8dKqlRP2blVkROYLZ2fLIjtWc/

[tj]

it's uber-ambiguous with our component.json, that's worrisome too, I'm often asked "why cant we install bower stuff with component" or "why cant bower install components" etc

[satazor]

We should converge to a single spec just like the AMD spec did.

[tj]

bower is fundamentally incompatible with component, that's the problem, as long as we both use component.json it's ambiguous

[sindresorhus]

bower is fundamentally incompatible with component, that's the problem, as long as we both use component.json it's ambiguous

I agree.

@fat Just curious, what's the reason it ended up as component.json instead of something more specific like bower.json?

[addyosmani]

@fat will correct me if I'm wrong. I remember back at the start we went through a few different .json names but settled on component.json as it best reflected bower was for components (i.e not just scripts, but packages of HTML/CSS/JS as well).

[tj]

well we have a spec pretty established, until then people will just have to choose between the two, not a huge deal but pretty confusing for most

[davetayls]

Can this be discussed further, I have been looking in to using bower and also looking at the work @visionmedia has been doing with components and it seems a shame to have two useful sources of package management so similar but incompatible.

[tj]

@davetayls they're not similar at all, that's the problem

[skiant]

@satazor Agreed. We shouldn't have to maintain god-knows-how-much files to handle the dependencies. We're working a project in team currently, and we already have two package managers (npm for the build system, composer for php dependencies) and we're considering using bower too.

It should be as easy as this: https://gist.github.com/4134821

[davetayls]

@visionmedia i clearly need to have a closer look, i see that they are both package managers but do they differ in that bower is purely for js/css whereas component allows tying in server and client functionality?

@paulirish I was glad to see #145 started 👍

[feross]

@visionmedia: "they're not similar at all, that's the problem" -- can you explain the difference between bower and components?

[tj]

@feross take a look at our spec / FAQ (or a few component implementations) they're fundamentally incompatible since we use commonjs, among other differences but that's the most obvious one, there's more different than there is alike

[sindresorhus]

I think Bower should change to use bower.json, with the temporary fallback to component.json.

Not only does it solve the incompatibility issue, but it also makes it more clear what the config file is.

[vendethiel]

agreed - I'm currently using it for clarity through the .rc file

[desandro]

I'm for bower.json, but while this is still in flux...

What if we coordinated with Component(1) to both use component.json? Clearly there are properties that could be shared like name, version, description, perhaps others. Everything that might conflict with another manager would be set within component or bower objects.

[sindresorhus]

@desandro

bower is fundamentally incompatible with component, that's the problem, as long as we both use component.json it's ambiguous

[paulirish]

Last I remember, the fundamental incompatibility is the unused main
property and nothing else, at least regarding the manifest... no?

On Mon, Jan 14, 2013 at 4:50 AM, Sindre Sorhus notifications@github.comwrote:

@desandro https://github.com/desandro

bower is fundamentally incompatible with component, that's the problem, as
long as we both use component.json it's ambiguous

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/110#issuecomment-12217111.

[vendethiel]

In this case, both could fallback to using name/blah/blah from package.json.
Also, the "fundamental incompatibility" is bower's agnosticism to method used to include them since component(1) is using commonjs.

[desandro]

The jQuery Plugins site has been relaunched. It relies on *.jquery.json manifest files. Now with component, bower and jQuery Plugins, developers could manage up to 3 manifest files.

Either someone will be a package manager manifest manager, or we can consider standardization.

Or maybe we can compromise can convince their tool to support bower/component.json in lieu of *.jquery.json

[sindresorhus]

4 if you count node.js compatible libs or those using package managers that extends package.json like Jam and Volo...

[jackmoore]

@desandro, I had the same thoughts and asked the jQuery team about consolidation. I don't think they are open to it: jquery-archive/plugins.jquery.com#116

Is it worth considering giving these projects different properties under the same json file? That way they could share universal properties (version, email, author), but have their own namespace (bower, component, etc.) for project specific configuration.

[desandro]

@jackmoore Thanks for the head's up. Looks like this is a moot issue on the jQuery Plugins team 💔 Yes, your inclination is exactly what I would advocate for.

We package managers are in a bit of a prisoner's dilemma where individually we can be self-interested and be successful individually, but if we only coordinated together we could achieve a greater goal. I don't feel this idealism is unrealistic. We're developers. We're smart people and we can get it done.

[necolas]

How do people want to do this? Shall we use the first post and this issue as the place to iterate and feedback on a spec? A new branch and we submit PRs / comments against a new spec file in there?

[guybedford]

Ok I don't want to pollute this thread too much - weary of the person who needs to be summing this all up!

So to keep it brief, @benschwarz my current view for builds would be modules should contain mains that are built but not optimized. So LESS as CSS, but retaining comments for example. This allows full sources for debugging in development, and then user will need a build tool for production anyway which should handle optimization based on reasonable defaults.

[benschwarz]

@guybedford & all, the assumption that all users will or even should be using a build tool is unrealistic. I do, you as committers probably do too, but you're misrepresenting a large proportion of the web design & development community.

Build tools are rad, but shouldn't be expected behaviour.

[mehcode]

@benschwarz Perhaps not a build tool. But there should be the expectation that everyone should at least be using some kind of minifier. I've never agreed with libraries distributing minified sources.

I see where you're coming from though. If we're imagining the random developer that doesn't understand how to (or doesn't want to) use a minifier / build tool, then I would venture to say that bower is not the tool for them. Something that consumes bower and provides that interface should be the tool for them.

[benschwarz]

@mehcode whats to say that my project will use any javascript library? What if I was only using prefixfree and normalize?

[mehcode]

I didn't say anything about javascript. When I said minify I meant CSS, Javascript, HTML, JSON, YAML, pList, whatever-files-you-happen-to-be-using.

There are several excellent CSS minifiers: https://github.com/rstacruz/css-condense and http://requirejs.org/ (yes it does CSS). I understand that its a lesser delved topic, but again — bower shouldn't be targeting developers who don't know this.

From what I understand bower was / is meant to be the low-level package management library that sits under everything and makes client-side javascript package management universal. There is room for jam / yeoman / component / brunch / etc. to consume bower and provide a newbie-friendly environment.

---

To make it clear: I agree with @guybedford. Libraries should be distributed built but not optimized. This is for debugging and development purposes. To not do so forces developers to not have the complete source for debugging, etc.; else, bower is distributing the file twice.

[necolas]

From what I understand bower was / is meant to be the low-level package management library that sits under everything…

Yes, exactly.

[danheberden]

I've been swaying about in my opinion of necessity about this, and there are a few points that have been big in this whole thread:

1. bower should offer all of the files necessary for a given package
2. some authors might opt to offer a compiled/minified version
3. bower should not be a build-tool, but it should definitely work well with one

As a plugin author, there are often two ways I would offer a compiled version of my package.

1. Build/Concat/Minify and commit that to my repo somewhere
2. Have a build process that makes the file(s) available on my webserver or somewhere

Either way, it is me, the author, that is making this available for consumers of my plugin. And if I'm doing this, it's already in a place that is available for consumption. If I don't do this, well, then consumers of my plugin are required to do it themselves.

So, take LoDash for example - there aren't any minified copies in the repo; those are on the website. So their bower.json could look like:

{ 
  "main" : ['lodash.js'],
  "components": {
    "default": "development:modern",
    "development": {
      "modern": "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.js",
      "legacy" : "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.compat.js",
      "underscore": "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.underscore.js"
    },
    "production": {
      "modern": "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.min.js",
      "legacy" : "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.compat.min.js",
      "underscore": "https://raw.github.com/bestiejs/lodash/v1.2.0/dist/lodash.underscore.min.js"
    }
  }
}

Basically, expose the ability to offer precompiled targets if the author wants to, otherwise show all the files. The next step would be displaying this information in a sane way to the user or exposing to tools that want to invoke bower (like grunt).

I think work, past this, might be too far reaching for a package manager. Thoughts?

[tj]

my .02 is that including minified stuff in your project doesn't make much sense, almost every application out there has some form of build step to aggregate/minify/gzip -> CDN on deployment. It's just extra work to do this in every single project

[danheberden]

@visionmedia haha @paulirish, @addyosmani and i were just debating that; i'm gonna update (and i agree)

[necolas]

I'm still against encouraging people to include variants of a component that should be generated by a build step - minified, prefix-free, etc.

[addyosmani]

my .02 is that including minified stuff in your project doesn't make much sense, almost every application out there has some form of build step to aggregate/minify/gzip -> CDN on deployment.

👍

[danheberden]

@necolas but this means consuming other build processes. In the case of lodash, for example, I don't want to have to incorporate that build process. I'd rather not use bower and just download the file I want to use with my build process then.

I was thinking offering targets would be a free win for minified files, but I see where that could lead to confusion and disorganization. And yeah, if you aren't minifying your other shit down the wire, what does it matter? You've already missed the point of best practice (as @paulirish mentioned to me).

So in the case of offering built versions, I think having the components object wish such would be really helpful - from before:

{ 
  "main" : ['lodash.js'], /* copy of lodash.js with all the comments 'n whatever */
  "components": {
    "default": "modern",
    "modern": "dist/lodash.js",
    "legacy" : "dist/lodash.compat.js",
    "underscore": "dist/lodash.underscore.js"
  }
}

[danheberden]

There is also the case of bootstrap, where the original files are .less - so again, to use it i'd have to compile less and do all kinds of shit that would mean i'd rather just get the files from the zip. What if:

{
  "main": ['js/**/*.js', 'css/**/*.less', 'img/**/*'],
  "components": {
    "default": {
      "source": "http://twitter.github.io/bootstrap/assets/bootstrap.zip",
      "main": ['js/**/*.js', 'css/**/*.css', 'img/**/*']
    }
  }
}

[necolas]

I don't really know, I thought last week we'd agreed not to get bogged down in trying to find solutions at this point in time for specific libraries that provide custom builds. With a proper publishing model, the handful of lodash variants could be published as their own components. Let's say it's better for them all to be in one package - what's benefit of being able to explicitly list each version of the component and point to URLs rather than files in the package?

Packages that require a compile step probably could distribute the compiled assets in the package. I previously proposed the use of something like ignore in .bowerrc so that a consumer can tell Bower to avoid installing certain file types if the project won't use them. Alternatively, Bootstrap could distribute 2 different packages. Not that clean I guess.

[tschaub]

If Bower doesn't specify a way to find the sources, how is it useful to a build tool?

For all the other stuff (modern, legacy, other variants) that might be included, I think this is better documented in a README. People can read docs and dig around the package that is downloaded. Its only the build tool that needs something specified in bower.json.

[satazor]

We really need to finish up the bower spec that is currently being done in google docs. @danheberden can we have this in the agenda for next monday's meeting?

[ambahk]

what if the package authors start defining the minimum browser version supported by their package in a new optional browserDependencies section?

e.g. the query 2.x bower.json will have this defined:

"browserDependencies": {
    "safari": "5.1+",
    "opera": "12.1+",
    "ie": "9+"
},

then the bower users can easily check the minimum browser versions required by their chosen packages and saves a lot of time testing.

[sheerun]

Specification has its own repository now. Please share your issues there. PR are also welcome.

https://github.com/bower/bower.json-spec