Comments (19)
Isn't it more friendly to use Git tag when available? Mostly as Bower registery is Github.
from spec.
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
from spec.
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.
from spec.
Perhaps @satazor can provide some insights?
from spec.
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 bower
requires the name. I've opened an issue name
should be required for published packages only #22
from spec.
This is already resolved: "Version should only be required if you are not using git tags.".
from spec.
@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:
{
"name": "bower",
"dependencies": {
"jquery": "2.1.0"
}
}
$ bower install # works fine
{
"name": "bower",
"private": true,
"dependencies": {
"jquery": "2.1.0"
}
}
$ bower install # works fine
Oppose to for example the way the name
attribute is handled i.e. you can't use bower without it.
{
"dependencies": {
"jquery": "2.1.0"
}
}
The above configuration is missing the name attribute and when you try to install it errors out:
$ bower install
bower EINVALID Failed to read /path/to/bower-test/bower.json
Additional error details:
No name property set
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 version
is explicitly optional.
from spec.
Yes, there's #22 for issue you're mentioning. This issue is resolved though.
from spec.
I know it's resolved. I'm asking is version
required for unpublished and private packages?
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 version
appears not to be required for private or unpublished packages.
Also, if version
is not required for unpublished and private packages, then the spec can be updated to reflect this.
Is it required for unpublished and private packages? :)
from spec.
Currently version is not necessary if package is not yet published.
I'm reopening since this can be clarified in spec.
from spec.
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 version
should follow name
and only be required when a package is public.
from spec.
It turned out version
is now deprecated in bower 1.x :)
We'll remove it from bower init prompt: bower/bower#1343
Bower already overrides version
with git tag after public packages are downloaded.
from spec.
This breaks RaveJS/rave which does runtime inspection of packages from the browser.
from spec.
Note: RaveJS is still under development. Many parts are incomplete at this time. Please give it a try, though, and let us know what you think. Or check out the open issues, if you'd like to contribute.
from spec.
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 name
, 'version,
moduleType, and
dependencies` (but there are certainly other bits we would like to use).
We use version
to handle large apps that may have more than one version of a library installed. Rave transforms the module names passing through the ES6 Loader into version-unique names. For instance, the "when/lift" module would be transformed to something unique such as "[email protected]/lift". jspm does something similar.
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 name
property, too?
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
from spec.
- We don't plan to remove
name
property from public packages. - Bower automatically fixes
version
property of bower.json, so it'll be available in installed component even if version is not specified in the original bower.json.
.bower.json
is hidden to not interfere with other files package specifies.
Sincerely I don't recommend consuming bower.json
in any case (bower/bower#1174). It's unprocessed file, and many packages are missing it. .bower.json
will be present even if bower.json
is not defined.
In your case you could run bower list --json --offline > bower.manifest
, and consume it in browser.
bower install --json
also returns appropriate output.
from spec.
Bower automatically fixes version property of bower.json, so it'll be available in installed component even if version is not specified in the original bower.json.
Sorry, just to be clear. You are saying that bower.json _will be modified_ if the version
isn't correct?
In your case you could run bower list --json --offline > bower.manifest, and consume it in browser.
Interesting! However, rave eliminates configuration. Generating more configuration isn't really an option. :)
from spec.
Pardon me. Only version in .bower.json
is fixed by bower. bower.json
is kept untouched.
We plan to release shrinkwrap feature that would automatically generate bower.lock
containing concatenated .bower.json
files. Would it fit you?
from spec.
I think we have a work-around, @sheerun. Thanks for your suggestions, anyways. Looking forward to more awesome bower features! :)
from spec.
Related Issues (20)
- bower validate? HOT 1
- Should `main` contain individual JS files or one concatenated JS file? HOT 4
- "overrides" property proposal HOT 3
- Proposal for an optional "supportedVersions" property HOT 2
- main and ignore are optional, but bower complains if missing HOT 1
- How should local components be specified and consumed to avoid duplication? HOT 1
- files: list all required files for build tools HOT 71
- Version the spec itself HOT 5
- Add the possibility to host custom fields in the bower.json HOT 5
- Rename repository to bower-spec and add .bowerrc specificaton HOT 5
- dependencies and devDependencies automatically pull the latest commit when url has #latest suffix ? HOT 1
- Inconsistencies for version, main, ignore attributes HOT 1
- Formatting of Deprecated is Confusing HOT 1
- example of environment variables seems incorrect HOT 2
- config spec does not document hooks HOT 1
- main property for es6 module version HOT 1
- Author clarification
- save and save-exact aren't listed in the spec
- Concurrent bower install error.
- Default value of `private` field is not specified. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.