version attribute should always be required about spec HOT 19 CLOSED

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.

@unscriptable

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, anddependencies` (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.

@unscriptable

1. We don't plan to remove name property from public packages.
2. 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.