Added bower.json to improve bower compatibility. #171

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
8 participants

Good afternoon!

I've added a bower.json file to improve es5-shim's compatibility with bower, and tools like grunt-bower-install.

Thanks!

Member

kriskowal commented Jul 22, 2013

Thanks, @kanerogers. I’m not willing to maintain multiple package.json files. I’m given to understand that this is not necessary for Bower or its ecosystem to function properly. @angus-c can you correct me if I’m wrong?

kriskowal closed this Jul 22, 2013

Ouch!

Fair enough, @kriskowal - this is totally reasonable. Maybe there's a way that grunt-bower-install could read from package.json instead. I'll look into it.

Thanks!

Member

kriskowal commented Jul 22, 2013

Thank you for your understanding. You are not the first to ask, and I get this request a lot on https://github.com/kriskowal/q as well, so were it only a decision of how best to serve users, I would concede and do appreciate your taking the effort to send a patch.

Contributor

jdalton commented Jul 22, 2013

I'm not sure what the problem is (besides the mild annoyance). Maintaining it is a win for users and costs you relatively little. I was initially all "I'll only support package.json", but then I realized I'm just hurting users, so I ended up maintaining them.

Sorry to bring this up again, but what is involved in "maintaining" a package.json? version is optional so you don't need to update it every time you push a tag. In fact, name is the only required field.

Owner

ljharb commented Jan 21, 2014

You absolutely need to update the version field whenever you release a version - if you're not going to stick with semver, don't publish on npm.

I'm not familiar with bower - what's involved in using bower.json? When releasing a new version, would I only have to update the version field there?

+1 for bower.json

Member

kriskowal commented Jan 22, 2014

Please do not pile on the +1’s. We know it would be a popular feature, as would component.json support, NuGet support, &c, and I would like to continue watching how @ljharb handles the issue.

Owner

ljharb commented Jan 22, 2014

There's a number of questions I'd have here with supporting additional manifest-based services:

  • what extra burden is there on whoever releases a new version?
  • need anything be uploaded to another service (besides npm, which is a given)?
  • How popular is $service? Even if we start supporting a few more, we will not just flatly accept any of them - I've heard lots about bower, less about component, and nothing about anything else, so I'd want some sort of justification that the service is widely used.
  • need the shim code be changed to support it? I'm generally opposed to anything that imposes restrictions on how the main modules are written.
  • is there the chance that nothing need be done? if there's additional cost for a "nice to have" but it's not strictly necessary for $service, perhaps it's best to leave it be?
Contributor

jdalton commented Jan 22, 2014

what extra burden is there on whoever releases a new version?

Usually find/replace version numbers in a directory. I handle this with my text editor.

need anything be uploaded to another service (besides npm, which is a given)?

If you publish to jamjs or nuget

How popular is $service?

jQuery supports bower, it's popular. I'd say add support as requests come in.

need the shim code be changed to support it?

I support bower, component, volo, jam, npm in my projects and haven't run into an issue
(besides minor nits in say assuming module is an object when it could be a function)

is there the chance that nothing need be done?

Sometimes you can do nothing. When package manager xyz is released they want to gain adoption so they pre-register popular projects. I'd say es5-shim falls into that category for some.

Owner

ljharb commented Jan 26, 2014

By the entirely arbitrary metric of "I've heard of it" I'd only consider bower and component for now as additions to npm - but if I'm signing up to maintain it, I'll want to make sure I actually understand how they work (I've never used either). So, while this PR / a PR for a proper component.json are/would be very appreciated, I'm going to have to get to this when I have time to do the full research.

angus-c commented Jan 26, 2014

You'd also need to register es5-shim with bower.

bower register <my-package-name> <git-endpoint>

If this were my project I'd get this done a.s.ap. so the name doesn't get taken (but note it requires bower.json to be in your repo first).

Re the maintenance issue — it should be minimal — just bump the version each time

angus-c commented Jan 26, 2014

@kriskowal to your question - yes you can install an unregistered bower module but it's more gnarly

without:
bower install git://github.com/es-shims/es5-shim.git
(alternatively the consumer can add es5-shim:git://github.com/es-shims/es5-shim.git in their bower.json dependencies)

with
bower install es5shim

Contributor

bryanforbes commented Jan 26, 2014

without:
bower install git://github.com/es-shims/es5-shim.git

This isn't entirely true. I can bower install dojo and Dojo doesn't maintain a bower.json. The link on the bower package list for Dojo also goes to the Dojo repo and not a third-party repo. There must be a way to register components without having a bower.json. Additionally, bower supports a shortcut for GitHub repos: bower install es-shims/es5-shim.

angus-c commented Jan 26, 2014

@bryanforbes yeah good call with the GitHub shortcut

Re. the bower.json requirement. See http://bower.io/#registering-packages:

There must be a valid manifest JSON in the current working directory

So I guess the existence of a package.json might be enough.

Owner

ljharb commented Jan 26, 2014

Here's my next question - with bower, if bower.json says "version foo", but master has since changed, which commit does bower install? Does it use conventionally named tags, or will it always pull the latest?

angus-c commented Jan 26, 2014

@ljharb bower always installs from a version unless you specifically ask it not to (e.g. by specifying master or another branch). That's the point of bower - give me the latest (or another named) version —as opposed to a work in progress.

Owner

ljharb commented Jan 26, 2014

@angus-c right - but if i say "version 1.2.3" does that point to a tag named "1.2.3", or "v1.2.3", etc? I don't see any documentation about how a bower version number maps to a git commit. Or, does bower register mark HEAD as mapping to the current version in bower.json?

angus-c commented Jan 26, 2014

@ljharb in the bower.json you declare the version name that the outside world will request. So for example flight.js has

version: 1.1.2

in the bower.json, but internally it is tagged as 'v1.1.2'

Consumers of flight will ask for '1.1.2' (or get it by default if they don't specify)

Owner

ljharb commented Jan 26, 2014

@angus-c OK, I think I get it, but just to be super clear :-) If a user tries to use bower to install a version '1.2.3', the git tag v1.2.3 will be used by bower to locate that version?

(Side question, what happens if that git tag doesn't exist?)

Owner

ljharb commented Jan 26, 2014

OK, so that means we'd need to have tag names without the "v" - but npm module convention is to always include the "v", so we'll need two version tags for every version. That might not be a bad idea anyways, but it's still unfortunate.

Contributor

jdalton commented Jan 26, 2014

"v" - but npm module convention is to always include the "v", so we'll need two version tags for every version

The version specified in the package.json is without a v. When I started adding support for package managers like component and bower switching to the non-v prefixed tags was the way to go (no need to maintain both). It hasn't caused issues anywhere else.

@ljharb ljharb added a commit that referenced this pull request Jan 26, 2014

@ljharb ljharb Adding bower.json
Fixes #171.
ec5afc8

angus-c commented Jan 26, 2014

@ljharb (deleted my previous comment - I misread your question)

So to your previous comment:

yes, so
bower install jordan-app#1.2.3

will in effect pull from the corresponding git tag name. Not sure what happens if you haven't yet made any tags - I assume it won't pull anything.

To your latest comment - not sure what you mean — package.json version names also don't have a 'v' prefix

Owner

ljharb commented Jan 26, 2014

The git tag in an npm module repo isn't used for anything, but community convention for version "1.2.3" is to have a tag "v1.2.3" to point to it.

Contributor

jdalton commented Jan 26, 2014

but community convention for version

Who what? There is no such convention. jQuery, browserify, express, Lo-Dash, underscore, optimist, requirejs tags are "v" less, and so on.

Owner

ljharb commented Jan 26, 2014

$ bower register es5-shim git://github.com/es-shims/es5-shim.git
bower es5-shim#*               resolve git://github.com/es-shims/es5-shim.git#*
bower es5-shim#*              download https://github.com/es-shims/es5-shim/archive/2.3.0.tar.gz
bower es5-shim#*               extract archive.tar.gz
bower es5-shim#*              resolved git://github.com/es-shims/es5-shim.git#2.3.0
[?] Registering a package will make it installable via the registry (https://bower.herokuapp.com), continue? Yes
bower es5-shim                register git://github.com/es-shims/es5-shim.git
bower                       EDUPLICATE Duplicate package

http://sindresorhus.com/bower-components/#!/search/es5%20shim says there's not one already. Anyone have any idea?

Owner

ljharb commented Jan 26, 2014

@jdalton look at the repos in many popular modules - it's a convention because a lot of people do it, and since most npm modules do not bother with bower/component/etc, I expect many don't run into this conflict.

Contributor

jdalton commented Jan 26, 2014

I just named off many projects that don't use "v" prefixes (many are the most popular on npm too). There is no need to worry about maintaining two tag versions (that's goofy).

ljharb referenced this pull request in bower/bower Jan 26, 2014

Closed

Unregister package requests #120

Member

kriskowal commented Jan 26, 2014

The npm version major|minor|patch command increments the version in package.json, commits it, and creates a v{version} tag. So the convention is symbiotic with the Node.js tooling.

ljharb referenced this pull request in bower/bower Jan 27, 2014

Closed

Support standard npm git tag conventions #1069

Owner

ljharb commented Jan 28, 2014

Looks like bower already supports having only v-prefixed tags in the git repo, so we'll stick with that convention.

Contributor

jdalton commented Jan 28, 2014

You'll run into it getting wonky-ish if you ever adopt component as its install syntax is component install es-shims/es5-shim@v2.3.0 which is odd since its so similar to npm install es5-shim@2.3.0.

If you remove the v prefix it's more consistent across package managers:
component install es-shims/es5-shim@2.3.0

angus-c commented Jan 28, 2014

@ljharb I think there's still some confusion. The name of the git tag is typically irrelevant to the bower install process. The version name for bower install purposes is the name you publish in the bower.json manifest [1]. So it is possible (and typical) to have bower.json declare version '1.2.3' and the corresponding git tag be 'v1.2.3'. This is also identical to npm numbering schemes.

the convention is to install with the registered name and version
bower install es5-shim#2.3.0
or simply default to the latest bower.json version
bower install es5-shim
or have your app's bower.json define es5-shim as a dependency and then use
bower install

[1] you COULD also install directly from the git tag
bower install es-shims/es5-shim#v2.3.0
but this is only recommended when the repo name is not bower registered

Hope this helps

P.S. I notice recent es5-shim version have two tags, one with and one without the v. This is isn't necessary

Owner

ljharb commented Jan 28, 2014

@angus-c Since I don't actually notify bower when I update to a new version, when I do bower install es5-shim#2.3.0, bower has to figure out what git commit references "version 2.3.0", so it knows what to install - what's the algorithm for this, if not looking up a git tag?

re the PS: I had created the alternate "no v" tags, but I've since deleted them.

angus-c commented Jan 28, 2014

I assume it uses the last git tag before the bower.json version bump

Owner

ljharb commented Jan 28, 2014

:-/ that flexibility is nice in that it means a repo can have its own tag conventions, but scary if a repo uses tags for anything in addition to tagging published releases. That makes sense if that's what it's doing though, thanks.

@n8downs n8downs added a commit to imvu/es5-shim that referenced this pull request Mar 24, 2014

@ljharb @n8downs ljharb + n8downs Adding bower.json
Fixes #171.
2241022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment