same component.json fields or different filename #39

Closed
tj opened this Issue Sep 12, 2012 · 87 comments

Projects

None yet
tj commented Sep 12, 2012

yooo. I planned on using github's search api to auto-discover projects with component.json files, removing the need for a registry or any user action at all, but the problem right now is we're both using component.json but in different ways, so we already re-introduced the ambiguity of package.json :s

Who is "we" in we're both using component.json ?

Owner

TJ, is there a discussion that captures the difference in the two
component.json designs?

tj commented Sep 12, 2012

so far just the main array I think. I've documented some things here, they're totally subject to debate if anyone has a problem with anything defined so far https://github.com/component/spec/wiki

tj commented Sep 12, 2012

actually I totally forgot the real issue hahaha, we're fundamentally using them both differently so there's no way to ever make them work with both. Deps of mine are defined as user/repo: version, and anything written for mine wont work with bower due to require() and vice versa, so it doesn't make sense for us to both use component.json

Contributor
jdalton commented Sep 12, 2012

I'm in a tricky spot as Lo-Dash and my other projects support browser, amd, commonjs, and node. I would like some help creating a component.json that works with both managers with a developer and production build of my libs.

Member

I'll stop short of suggesting a bower.json file as I know that this project has already shifted from the naming on the main package configuration point once before already :) In an ideal world, we wouldn't be encouraging multiple registries/package managers to each use their own dedicated package file.

@visionmedia if discoverability is a concern, are you able to search for files of name component.json that also contain main or another piece of meta-data specific to your project?

tj commented Sep 12, 2012

yeah that's the fundamentally flawed portion I'm attempting to get away from, really sick of supporting so many different things. All of them can be derived from a more declarative (commonjs) script though so that's the way I'm going haha. For example I'm refactoring Mocha to use components and I'll just do component build --standalone to wrap it up as something people can use without component(1) itself.

@addyosmani it's not just the discoverability portion, though that would be handy, but even just as a regular user looking around at code, it would be nice to see "component.json" or "bower.json" etc and just know that you can use it, and obviously we can't have two component.json formats so that breaks down right away

Member

it would be nice to see "component.json" or "bower.json" etc and just know that you can use it, and obviously we can't have two component.json formats so that breaks down right away

Yeah. That's very true. I'd be interested to hear what @fat @caniszczyk etc think about this.

Contributor
jdalton commented Sep 12, 2012

@visionmedia

yeah that's the fundamentally flawed portion I'm attempting to get away from, really sick of supporting so many different things

It's not flawed for my projects and I have build options to narrow its scope. As a lib dev I just want to make my lib as available/reachable as possible. I'm starting to get the feeling most of these package managers are half baked and that makes me think there is little utility in supporting them.

tj commented Sep 12, 2012

yeah but that's exactly what I'm aiming for, we shouldn't have to manually be supporting AMD / require etc all the time, and globals are certainly the wrong way to go, builds should take care of these inconsistencies for us, and those who want to live in component-land from a consumption standpoint will have an even easier time since you dont have to manage a ton of globals.

The current state of client dev is pretty poor, for example even hammer.js which did the "right" thing and didn't depend on jquery etc, has to inline several things for binding / unbinding events, those shouldn't be concerns for it. If something like that were built with component, you would simply add the deps you need and build with --standalone for regular global consumption

Contributor
jdalton commented Sep 12, 2012

@visionmedia

yeah but that's exactly what I'm aiming for, we shouldn't have to manually be supporting AMD / require etc all the time

Ya but supporting those is now trivial-ish, however, as more package managers are created adding a ton of xyz.json files is going to get old. I loved how easy it was to tap into Jam by just adding 1 key to the package.json that I was already using.

tj commented Sep 12, 2012

it still shouldn't even be a concern IMO, certainly not something I want to do all the time.. we already have ~150 components or so. Different goals I guess..

Contributor

Seems like a common definition shouldn't be too hard to come up with (just pick one to start with and augment until all reasonable cases are satisfied). Once that is done, it seems like component.json (since many have stated that they don't want package.json for one reason or another) should get the green light.

Who will start that wiki page?

tj commented Sep 12, 2012

@wilmoore it doesn't matter, they're fundamentally different things, bower packages wont be compatible with mine etc. The scope of bower is much much smaller so package.json should be fine I'd think

Contributor
jdalton commented Sep 12, 2012

@visionmedia @addyosmani both projects have supported Underscore, jQuery, and other libs that currently lack engaged support, so how would you all suggest similar libs that want to actively support both package managers proceed?

tj commented Sep 12, 2012

in this current state you can't support bower / component at the same time I guess :s

Owner
necolas commented Oct 1, 2012

Yeah, it's a real shame these are currently incompatible if you specify dependencies :/
FWIW, I like not having to register a component and worry about people squatting on the name when using 'component'.

Member

We should change to bower.json.

Benefits

  • Removes exclusivity with Component. As a component developer, trying to choose between either makes me choose neither.
  • Brand awareness - people see bower.json when viewing repos itop-level in GitHub repo. It's more unique for easier search-ability.

Costs

  • Possibly breaks compatibility with anyone currently using component.json for Bower
  • More development resources to maintain backwards compatibility with legacy component.json

@sindresorhus comments this is not a big deal in #125 and I agree. We should pull off the band-aid now while it's still fresh. It's preventing us from doing bigger things.

Owner

I support this. Now is the time to do these kinds of changes.

Owner
satazor commented Nov 18, 2012

@sindresorhus along with various fixes and some features, I removed package.json support.
I can now make bower.json the defaul and component.json the fallback.

Btw, do you use gtalk? I made you an invitation

Owner
necolas commented Nov 18, 2012

IMO, there would have to be a clear roadmap for Bower deprecation of component.json support altogether, so that package authors understood the need to make updates. Otherwise, we'd still be left with conflicts at some level due significant fragmentation of bower package configs.

Owner

@necolas Absolutely. It's all about clear deprecation timeline and evangelism. I've created a ticket to get a roadmap discussion going in #145

+1 bower.json
But do both projects use the component folder too?

@desandro desandro referenced this issue Nov 20, 2012
Closed

Roadmap #145

+1 for bower.json
component.js is too generic and looks clumsy as part of web application.

Contributor

+1 for bower.json

Member

+1 for bower.json. I would love to see this happen sometime soon and agree 100% with @necolas that a deprecation plan is needed for component.json.

Owner

Looks like bower.json it is.

Suggested plan:

  • Add support for bower.json in next release and warn about component.json
  • Remove support for component.json in Bower 1.0 (far off)
  • Document the replacement of component.json and deprecation path clearly in the readme.
Owner
satazor commented Jan 29, 2013

I'm preparing the 0.7.0 release and I'm thinking in including bower.json in it.

@necolas Can you please ask your twitter fellows if they have any problem with it?

Owner
necolas commented Jan 29, 2013

@satazor Will do.

Could be worth talking about the pros/cons of moving away from placing bower modules in components by default. Two reasons to change it: Component(1) also uses this; it isn't very clear that the code in that directory is managed by a package manager (whereas "node_modules" doesn't leave much doubt).

Since we're moving to bower.json we could also move to bower_modules or something. People who need to retain the component.json and components dirs are pretty quickly going to have to explicitly do so using .bowerrc. But for now, we could ensure that if component.json is being used, the modules go in components.

I agree with @necolas

bower_modules seems ok to me, at least it's kind of obvious what's going on.

Owner

How about bower_components?

I'm currently using bower/ but I'd be okay with bower_components

bower/ is ok too. no ambiguity there :)

Owner
satazor commented Jan 29, 2013

I like bower_modules, same convention as npm. @addyosmani whats your thoughts on this?

Owner

We are still pushing the term components for Bower. I don't think we should mix terms by starting to use modules.

Owner
satazor commented Jan 29, 2013

If we make it bower_modules then https://github.com/components also do not make sense anymore (the name of the organisation).

Owner
necolas commented Jan 29, 2013

Ideally, it would be good to make a decision looking to the longer term - so not too concerned about the existing name of the shim-repo-org thing (it only has 9 repos anyway).

We are still pushing the term components for Bower. I don't think we should mix terms by starting to use modules.

The terminology might already be mixed. Aren't they really "packages", as is the term used by Node, Python, Go, etc? They become modules or components in your system once you depend on them :)

Owner

Ideally, it would be good to make a decision looking to the longer term - so not too concerned about the existing name of the shim-repo-org thing (it only has 9 repos anyway).

But aren't we really paving the way for Web Components?

Aren't they really "packages", as is the term used by Node, Python, Go, etc?

I think the definitions are really loose regarding this. As you said yourself, we should look to the future and not the past. The future, IMHO is web components, and that's why I think we should stick to that term.

Owner
necolas commented Jan 29, 2013

Web Components are something else entirely.

would just using bower/ side step the issue?

Owner
necolas commented Jan 29, 2013

IMO, bower is a confusing project-level dir name. It would be a bit like having a dir named node or npm in your project root.

Owner
satazor commented Jan 29, 2013

@necolas @sindresorhus has created a milestone for 0.7.0 and I've added tickets I feel it should be resolved. This is one of them. If we got no answer from the twitter folks regarding the rename to bower.json, I'll remove it from the milestone.

Owner

Cons of bower.json

  • other tools that may use this manifest have the awkward position of
    using a file with a "proprietary" name
  • it doesnt feel very canonical
  • npm's manifest not being called npm.json didn't slow it down
  • Two projects right now currently incompatibly share component.json.
    Bower has 858 packages published. Component has 573.
  • It's a massive change for the community. We basically start from 0
    with this.

If changing the manifest for bower is a must-do, then I'd rather persue
sharing package.json rather than moving 900 packages to a new file.

On Mon, Jan 28, 2013 at 8:54 AM, Sindre Sorhus notifications@github.comwrote:

Looks like bower.json it is.

Suggested plan:

  • Add support for bower.json in next release and warn about
    component.json
  • Remove support for component.json in Bower 1.0 (far off)
  • Document the replacement of component.json and deprecation path
    clearly in the readme.


Reply to this email directly or view it on GitHubhttps://github.com/twitter/bower/issues/39#issuecomment-12791389.

I think @fat's issue with using package.json was that he didn't want to imply that bower was an npm/node specific tool. I'm assuming so communities around other languages would feel comfortable using it. Whether or not that's a valid point is up for debate I guess? Do Ruby/Python/Java devs shy away from package.json?

@satazor satazor closed this Jan 29, 2013
Owner
satazor commented Jan 29, 2013

Ops missclicked

@satazor satazor reopened this Jan 29, 2013
Owner
satazor commented Jan 29, 2013

Regarding the file change we could mitigate the slow change/adoption by doing a script that would create a PR to all the registered repos with a message explaining the change.

afeld commented Jan 29, 2013

Ha, that might be crazy enough to work!

Member

My two cents: a decision on this should be shelved for 0.7.x so that the next release isn't held up by it. I feel the community needs more time to discuss whether bower.json is the right solution and I agree with many of Paul's reservations about the change. Further time is probably needed to come up with the script @satazor mentions earlier anyway regardless.

tj commented Jan 29, 2013

FWIW in most cases it's not a huge huge deal conflict-wise (other than confusion maybe), because most non-component libs are not really designed as components, they have lots of inlined x-browser bagage, globals, do way too much etc. So in most cases maybe excluding things like underscore or utility related projects I dont think the conflict is a massive deal, especially because for example not a single jquery plugin out there would be considered a "good" component

Owner
satazor commented Jan 29, 2013

If we decide to move to bower.json, the script I suggested earlier might sound crazy but would work pretty well.
People have to deal with backwards incompatibility now and then, and have to investigate what changed.
By issuing a PR to all the repositories, we take the burden out of package owners. The only thing they need to do is understand the reason for the change and merge the PR. It could also cause a positive wave in the JavaScript community, bringing more interest on bower and perhaps more adoption (twitter, google+ shares etc).

tj commented Jan 29, 2013

that's what I used https://github.com/component/bot for (you could probably use the same script), to add a few properties that were not defined earlier in the spec. I wish npm did this sort of thing for Readmes instead of bitching that you're missing a readme, that's really annoying as a user

Contributor

Love the PR bot idea here (and I would prefer "bower.json").

Owner
satazor commented Jan 29, 2013

Thanks for sharing that @visionmedia, will be very useful if we actually decide to do it.

Owner

it doesnt feel very canonical

What is canonical in our case?

Even npm doesn't adhere to the CommonJS packages spec.

Bower has 858 packages published

But very few of them actually have a component.json: https://github.com/search?q=component.json&ref=commandbar

We basically start from 0 with this.

As shown above, we don't really do that.

Owner
necolas commented Jan 29, 2013

Preface: I'm not 100% convinced by any of the options; my opinion is neither set in stone nor (even close to) fully informed.

other tools that may use this manifest have the awkward position of using a file with a "proprietary" name

That also ensures that we can do what we want without worrying about blowing up other tools. Also, see https://twitter.com/izs/status/293549138753249281

Bower has 858 packages published. Component has 573.

The disparity is probably even greater when you consider that TJ authored a good number of those.

It's a massive change for the community. We basically start from 0 with this.

Yeah, it's not something you'd wish for. But people would have until 1.0.0 to migrate, and the system could be aided with tooling and author-facing warnings. If a change needs to happen, getting it out of the way sooner rather than later will make it a smaller change.

If changing the manifest for bower is a must-do, then I'd rather persue sharing package.json rather than moving 900 packages to a new file.

A good number of those packages aren't using package.json either.

My two cents: a decision on this should be shelved for 0.7.x so that the next release isn't held up by it. I feel the community needs more time to discuss whether bower.json is the right solution and I agree with many of Paul's reservations about the change. Further time is probably needed to come up with the script @satazor mentions earlier anyway regardless.

We've already gone round and round in circles with this issue for the last few months. A change this big certainly shouldn't be part of a patch release.

But it basically boils down to either Bower changes the name of it's config file, or we just carry on and don't care. Component(1) can then decide what it wants to do.

tj commented Jan 29, 2013

I dont really care personally now that the auto-discovery thing is out of the picture

Owner
satazor commented Jan 30, 2013

If we carry on with component.json, package authors that want to make their library available to a wide variety of package managers, have to opt between component(1) or bower. This happened to @jdalton with lodash.

I've been thinking a lot about this. In the end, if we put everything in balance, I think we got more advantages in transitioning to bower.json. The transition wouldn't be that hard because only a few packages actually have a component.json and the PR bot would take care of them.

Anyway, I'll remove this issue from the 0.7.0 milestone but we really need to sort this out for 0.8.0.

Owner
satazor commented Jan 31, 2013

If we carry on with component.json, package authors that want to make their library available to a wide variety of package managers, have to opt between component(1) or bower. This happened to @jdalton with lodash.

This is no longer true. The name of the json file can now be configured package-wise (via .bowerrc). Please see #205, for a the complete reference and how we resolved it. This is very important for this issue since it mitigated a lot of issues that package owners had if they wanted to make their package available to both bower and component(1).

geddski commented Feb 2, 2013

bower.json seems the right choice to me.

Owner
satazor commented Feb 17, 2013

@necolas Any news from the twitter folks?

Owner
necolas commented Feb 17, 2013

No one raised any objections. We can double check on Wednesday.

Owner

ping

Has it been considered to just have uniquely-bower json fields, instead of having our own entire file?
This could even be done with component too, and maybe everything could be deprecated in trade for package.json

Owner

@devinrhode2 it has been discussed at length. search the tracker.

  • other tools that may use this manifest have the awkward position of
    using a file with a "proprietary" name
  • it doesnt feel very canonical

I agree with Paul here. I'm using Bower's component.json for the CommonJS/AMD build tool I'm developing (Vaccine.js). Any libraries using the tool will get Bower support "for free", which would lead to more packages getting published, which may (however slightly) help Bower become the dominant package manager.

With a name like bower.json, it becomes very unclear as to why Vaccine would use that name. component.json on the other hand makes sense because the tool helps with developing components.

Just to offer a different perspective here... I'm not invested at all in either Component or Bower, as I have been playing around with both (and others) and trying to do some research on all the client package manager options out there.

From what I can tell though, Component is a fairly known project that has used the component.json file first. To me, as just a regular developer, it seems very grimy for someone afterwards to come along and bulldoze right through that with no respect. Regardless of which approach is better or more popular, the simply polite thing to do is to consider more than just the technical aspects of the issue but also the social aspects as well. I'm just sayin, it's one thing to say you were unaware before it became too late, but at this stage (relatively new project) it doesn't really make sense to say the technical challenge is too hard or that it would be a setback to the community. To me it just says we don't give a crap and we'll do what we want; other developers can suck it. I'm just putting that out there as it hasn't been mentioned yet in this thread and is definitely something that will (at least slightly) influence opinions about the project (until at least one or the other goes away, if ever).

That aside, again as just a regular developer, I also find it easier to figure out what's going on without the naming conflict. Registries sites/services are fine and good but sometimes you are just browsing to a repo and it's nice to be able to know what kind of tools it supports at a glance.

Owner
necolas commented Feb 26, 2013

@endium I think it would be best if you assume that you don't know the details, rather than accusing people of having no respect, etc. Thanks for your thoughts.

I'm fully admitting that I don't have the details. Sorry if you took it that way bro but I'm not calling anyone in particular disrespectful. Just that from the outside, as someone who doesn't know the actual motivations of the decision makers in the project, that's simply how it would appear if after this discussion Bower decided to continue using component.json. Things like mentioning which project has more github "stars" and quotes like "But it basically boils down to either Bower changes the name of it's config file, or we just carry on and don't care. Component(1) can then decide what it wants to do." are the kinds of things that give off that impression. Whether I know the details or not doesn't change how it looks.

EDIT: I'm not using Component or Bower at this point anyway so it's not about that. I just think it's better for the open-source community when projects try to avoid blatant incompatibilities with each other, which seems pretty reasonable when a project has not even reached 1.0 yet.

Owner
necolas commented Feb 26, 2013

Yes. This entire thread is about trying to avoid the current incompatibility. In the context of the wider discussion, my point about "carry on and don't care" was that it isn't a viable option.

I have an idea, inspired by @desandro's comment about a package manager manifest manager.

Create a new json file that is package manager agnostic for its top-level fields. Then have any differences that a certain package manager needs be specified as a field with the same name as the package manager.

I've written out a very crude spec for such a json file here. I'm calling it library.json, but that could certainly change.

Since it seems like component.json is getting dropped, Bower could use library.json directly, but with a "bower" field for anything that is Bower specific. Bower would not "own" library.json, however. We've seen what happened with package.json and npm.

I don't want to derail this thread, so feel free to discuss on this gist.

Personally, I'm not totally convinced that bower and component(1) are incompatible. I think component(1) does have a larger scope (in terms of what it does for its smaller-scoped components) and Bower has a smaller scope (with packages often being much larger) - but that doesn't mean the two can't be reconciled!

(Note: like many people in this thread, I have both used neither package manager and only have passing experience with both, so I may be wrong on both counts).

In the most recent meeting notes, they talk about using postinstall scripts / bowerhooks to handle SASS / Less + AMD / require - oriented assets. This is (if I understand correctly) kind of what component(1) already does, only implicitly (from what I understand tj hates the idea of having to add boilerplate / wrappers of any kind to mark something as unopinionated). Couldn't component(1)'s components be altered to work with bower if their AMD/require compilation steps are added as a field in component.json (perhaps something explicit for just this purpose, like "scripts": {"buildjs": "node ./commonjs-wrap.js"}, so it wouldn't interfere with any post-install scripts component(1) may want in the future)?

The other major conflict, as I understand it, is in the definition of dependencies. This is my understanding of how component does it:

"dependencies": {
  "ghusername/packagename":"semver",
  "git://git-repo/package.git": "semver"
}

And how bower does it:

"dependencies":{
  "packagename-in-bower-registry": "semver",
  "packagename-from-github": "ghusername/packagename#tag-or-semver"
  "packagename-from-any-git-repo": "git://git-repo/package#tag-or-semver"
}

(If I'm wrong on either of these, please point this out and let me take the correct version into account.)

The component(1) mindset is that describing the github repo name sidesteps having to set up your own package tracker, in favor of depending on github. Bower's approach removes Github from the equation (allowing a package to come from anywhere), but doesn't necessarily remove Github from the realm of possibilities (since you can specify any Git repo, and I think it does special-case Github).

I prefer the second approach to the first one (letting package names be explicitly separate from their location), but it strikes me that the two forms of dependencies aren't conflicting. Bower could support Component's dependency specification by making it so any dependency name containing a slash is interpreted as {"ghusername/package":"version"} and translated to {"package":"ghusername/package#version"} (and component could theoretically get its modules from anywhere).

I would really like to see a future going forward where component(1) and bower have a symbiotic relationship, and I think that, despite having different concerns, they don't have to be competitors.

tj commented Feb 27, 2013

@stuartpb post-install is a bad idea IMO, then you're forcing people to have all those tools installed. With component(1) the general rule is to precompile for public things, or when feasible ignore jade/sass etc all together. In your own app we have build hooks you can tap into for whatever you like (we use stylus / jade etc in our app).

Also namespacing is frankly one of the nicest things about component, fighting over names in a centralized registry is really terrible. There's no reason for us to use bower even if they could be compatible, component is much faster at installing, so saving ~500 lines of code isn't really worth delegating to a different package manager.

The reason they are fundamentally incompatible is because of the dependency definitions as well as the commonjs support we have, we want an ecosystem built off of smaller logical components, not to be re-using poorly abstracted jQuery plugins etc even if they were auto-wrapped.

We're also not coupled with GitHub, that's just a misconception, being coupled with git is a bigger burden than being coupled to a <user>/<repo> pathname.

@visionmedia I agree that having namespacing offloaded to github is a nice thing, which is why I'm suggesting that bower recognize package locations in package keys to allow for it (since, from my understanding, it already does in a slightly more verbose "packagename": "username/packagename#version" way). That way, if you only want to specify your dependencies the component(1) way (ie, if you're already written for component(1)), then you can do all your dependencies like that, and ignore the idea that there's a centralized repository of package names to fight over altogether (and just focus on Github's centralized repository of org/usernames to fight over).

As it is, bower (from what I understand) only supports only-alphanumeric-hyphens-and-underscores package names as keys right now, and component supports everything BUT only-alphanumeric-hyphens-and-underscores names (as every package name must specify its location). So, from a technical standpoint, they aren't really incompatible (there's no valid entry that could be written for both that would specify a different repo to pull from for either). Bower could support component(1)'s approach to package names/locations, or at least ignore them if encountered, and component(1) could likewise support or ignore bower's approach (even only translating Bower's way of specifying explicit locations and ignoring/erroring implicit locations so as to preserve component(1)'s disuse of any single name registry).

if you're supporting browser-ready files as a pre-package step (again - I think this is a really great approach, for the reasons you mentioned), then that's the way you do it, and that's the culture you push. (Could CommonJS / require / AMD be added to this pre-package step?) Other packages have the right to be wrong and require that the user have a bunch of devDependencies or whatever to install, and may be opinionated or just generally not play nicely with others, but that can be solved, by the user, in the future, by switching to a version of the package that works better in their ecosystem because it was put together following The Component(1) Way.

As for the commonjs support: maybe I don't understand this quite as well as I'd like. What does component(1) do for its packages here? How does that relate to / differ from the other projects bower intends to integrate with such as Jam / Volo / Ender?

tj commented Feb 27, 2013

There's a lot of re-inventing with components right now, but that's by design. We don't need 15 tip implementations like jQuery etc, do it once and do it right. I have no interest in supporting AMD or globals, that might get you a larger package number but we want quality not quantity. Sure you could try to hack in support for a bunch of them but then you're just ending up with a brittle mess, even npm's support for both GH style and unique name is pretty poor IMO, by opting in to GH style you're basically saying your package isn't important enough to be in the registry at that point, so you're forced to use some stupid name for it.

tj commented Feb 27, 2013

haha nice timing: visionmedia/superagent#185

@lboynton lboynton referenced this issue in segmentio/analytics.js Mar 6, 2013
Closed

Using analytics.js with Bower #104

a few thoughts..

https://github.com/components also do not make sense anymore (the name of the organisation).
As an outsider to both projects, it's confusing that github.com/components and github.com/component belonged to 2 separate package manager projects. I realize it's a pain to change names but it would make a lot more sense to have bower not leak into the component project's namespace. Going a step further, if the name change were to happen it would be super polite to actually yield both of them to @visionmedia to cut down on confusion and alias them. That being said, "components" is probably one of the worst name choices in terms of ambiguity. Bower is distinctive and brandable.

@paulirish I agree with your sentiments re: npm's manifest not being called npm.json didn't slow it down though considering historical context, the npm team didn't anticipate it becoming so popular that it would host things besides node modules. Back then package.json made perfect sense, because npm.json would have been redundant since we were only declaring a node package.

I don't want to derail this conversation thread but I'd like to say in passing that I think component project is spot on here in not tying front end packages to npm. I am an avid node developer and I don't think it's good to "pollute" npm with stuff that has nothing to do with node. Despite Isaac saying that they don't have a problem with non-node things getting into npm, I think this is short sighted in some ways. Just because the signal:noise ratio isn't high enough to make a fuss over when searching for node packages right now doesn't mean it wont happen in the future as more stuff gets thrown in there. 6 months ago there were around 18k modules. Now there are almost 24.5k. It's rapidly growing. It's almost at the point where discovery is impossible. This whole effin thing is going to come crashing down..

Contributor

@mreinstein

👍

@twitter

Forgive me if this has already been done (I quickly scanned the commits but did not see it); however, it would be awesome if someone would pull the trigger. If someone submitted a pull request, would that be sufficient or is there something else outstanding? I've been periodically re-scanning this issue (casually), so perhaps I've just missed it.

Contributor

Well, I guess this is the answer for now:

You can use bower.json (which we're moving towards as the default) or a custom name referenced in your .bowerrc. Check the Bower README for details.

via: #37 (comment)

Owner

Started hacking on a PR for this. Currently my plan is:

  1. Change every mention of component.json to bower.json.
  2. Change component.json to bower.json in all of the test fixture components to make existing tests pass
  3. Add in extra logic so that if there is no alternative json name defined through .bowerrc and bower.json does not exist, try falling back to component.json. Issue a deprecation warning if this happens.
  4. Add new tests for component.json fallback and the deprecation warning.

Is everyone ok with the fallback for backwards compatibility? Old versions of bower wont handle projects using bower.json (unless the author includes a .bowerrc), so we aren't going to be backwards compatible in that direction anyway.

Owner
necolas commented Apr 4, 2013

ok with the fallback for backwards compatibility

Yes, I am. The CLI should also throw a "warn" when you install packages that have dependencies with component.json. We'll need to evangelize about this change. Then I think we should drop the backwards compatibility when Bower hits v1.0.0. Let's see what Andre thinks.

Owner

Agreed on all counts, @necolas @wibblymat

Though I don't like that the .json can be different due to a line in .bowerrc - though i don't like having this file at all except for possible global settings in the user's home dir.

@wibblymat sounds like a good plan.

Owner
Owner
satazor commented Apr 5, 2013

I also agree. Be sure to add complete tests for this change

@satazor satazor closed this in c9068f5 Apr 8, 2013
@kelonye kelonye referenced this issue in components/ember Apr 9, 2013
Closed

Add Component Support #10

RobLoach commented Apr 9, 2013

Once the next stable release of Bower is out with bower.json support, I'd be more than happy to update the packages in http://github.com/components accordingly. Name confusion aside, it's great to see a push forwards like this. Thanks to all involved! 👍

@desandro desandro locked and limited conversation to collaborators Jun 17, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.