Skip to content
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

Closed
benschwarz opened this issue Nov 11, 2013 · 19 comments
Closed

version attribute should always be required #4

benschwarz opened this issue Nov 11, 2013 · 19 comments

Comments

@benschwarz
Copy link
Member

No description provided.

@SBoudrias
Copy link

Isn't it more friendly to use Git tag when available? Mostly as Bower registery is Github.

@eddiemonge
Copy link

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

@desandro
Copy link
Member

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.

@benschwarz
Copy link
Member Author

Perhaps @satazor can provide some insights?

@gerardroche
Copy link

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

@sheerun
Copy link
Contributor

sheerun commented Apr 19, 2014

This is already resolved: "Version should only be required if you are not using git tags.".

@sheerun sheerun closed this as completed Apr 19, 2014
@gerardroche
Copy link

@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.

@sheerun
Copy link
Contributor

sheerun commented Apr 22, 2014

Yes, there's #22 for issue you're mentioning. This issue is resolved though.

@gerardroche
Copy link

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? :)

@sheerun
Copy link
Contributor

sheerun commented Apr 22, 2014

Currently version is not necessary if package is not yet published.
I'm reopening since this can be clarified in spec.

@sheerun sheerun reopened this Apr 22, 2014
@benschwarz
Copy link
Member Author

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.

@sheerun
Copy link
Contributor

sheerun commented Jun 9, 2014

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.

@sheerun sheerun closed this as completed Jun 9, 2014
@unscriptable
Copy link

This breaks RaveJS/rave which does runtime inspection of packages from the browser.

@eddiemonge
Copy link

@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.

@unscriptable
Copy link

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 "when@3.2.3/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

@sheerun
Copy link
Contributor

sheerun commented Jun 10, 2014

@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.

@unscriptable
Copy link

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. :)

@sheerun
Copy link
Contributor

sheerun commented Jun 10, 2014

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?

@unscriptable
Copy link

I think we have a work-around, @sheerun. Thanks for your suggestions, anyways. Looking forward to more awesome bower features! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants