-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version attribute should always be required #4
Comments
Isn't it more friendly to use Git tag when available? Mostly as Bower registery is Github. |
im mixed on this. itd be nice to see it when you have a packaged installed but you can look at .bower.json to see it and not having it is one less place to update when doing releases for new packages |
resolving mismatched versions between bower.json and git tags feels like nuisance. But I understand there must be some technical reason for keeping both. I'd be interested in hearing what this technical reason is and how to resolve it. |
Perhaps @satazor can provide some insights? |
It should only be required for published packages, otherwise it's redundant. This is also true for the name field. In example, both composer and npm only require version and other fields like name for published packages. In fact, the version is optional in composer. Currently |
This is already resolved: "Version should only be required if you are not using git tags.". |
@sheerun What about unpublished and private packages? I've tested on v1.3.2 and it looks like the version is not required in those use cases. I think this is the correct functionality i.e. the version should not be required for unpublished and private packages, because in those use cases it is redundant and only serves to force the consumer into adding meaningless metadata. In v1.3.2 both of the following configurations work without any issues, which is sweet:
Oppose to for example the way the
The above configuration is missing the name attribute and when you try to install it errors out:
I've opened and issue about this. My point is, consumers should be able to use bower without being required to configure it with meaningless metadata i.e. there are reasonable use cases where the |
Yes, there's #22 for issue you're mentioning. This issue is resolved though. |
I know it's resolved. I'm asking is The reason I ask is because I'm confused. You said: "Version should only be required if you are not using git tags.", however, I tested on v1.3.2 and Also, if Is it required for unpublished and private packages? :) |
Currently version is not necessary if package is not yet published. |
The issue was raised as a conversation piece following a bower team meeting. Sorry the conversation never followed! 🎣 I agree with the sentiments of #22 — I believe that |
It turned out We'll remove it from bower init prompt: bower/bower#1343 Bower already overrides |
This breaks RaveJS/rave which does runtime inspection of packages from the browser. |
|
Hey @sheerun, One of rave's goals is to eliminate configuration and machinery. One of the ways we've accomplished this is via two modes of development: responsive and built modes. In responsive mode, the run-time environment in the browser discovers -- and responds -- dynamically to the environment. When using bower-managed dependencies, bower.json is the only reliable place to discover the environment from a browser. (The .bower.json file is hidden by all web servers by default so it is not discoverable.) The most vital pieces of information are We use I know bower can't currently support multiple versions, but npm does. Rave transforms the names to support multiple versions in npm. Rave allows devs to combine npm and bower in the same app. Believe it or not, it's all working quite well, atm. :) I guess we could change rave so that it treats bower packages as unversioned. This could probably work without a ton of effort. However, am I correct in assuming that we're also debating whether to remove the If we remove all of this discoverable meta data, rave just can't work with bower any more. An alternative would be to stop hiding .bower.json. Is this a possibility? I've read the threads about why .bower.json exists, so I understand that the bower committers have decided not to mangle the original bower.json. TBH, the fact that the file is hidden indicates that it's meant for bower internal use, not for use by third-party build tools, etc. If there's a possibility that we could stop hiding .bower.json (by naming it to something not hidden/private/undiscoverable), that would be awesome and would level the playing field between npm and bower. I guess I'll open an issue. :) -- John |
Sincerely I don't recommend consuming In your case you could run
|
Sorry, just to be clear. You are saying that bower.json _will be modified_ if the
Interesting! However, rave eliminates configuration. Generating more configuration isn't really an option. :) |
Pardon me. Only version in We plan to release shrinkwrap feature that would automatically generate |
I think we have a work-around, @sheerun. Thanks for your suggestions, anyways. Looking forward to more awesome bower features! :) |
No description provided.
The text was updated successfully, but these errors were encountered: