Bower: Installing dependency from URL and specify version

[olach]

Headroom.js have unregistered the package from Bower and suggests the users to install the package this way instead:

bower install https://npmcdn.com/[email protected]/bower.zip --save

This installs the specified version. In bower.json this line is added:

"headroom.js": "https://npmcdn.com/[email protected]/bower.zip#^0.9.3"

If a co-worker runs bower install the installer gives an error. (ENORESTARGET URL sources can't resolve targets). Bower don't like the version added to the end of the URL.

I have to manually delete the added version at the end for it to work as expected:

"headroom.js": "https://npmcdn.com/[email protected]/bower.zip"

The author of headroom.js tried this with an earlier version of Bower (v1.7.7) and in that version, Bower did not add the version to the end of the url. He continues and says that this is a problem with bower itself, since it used to work in earlier versions and the URL https://npmcdn.com/[email protected]/bower.zip#^0.9.3 behaves as expected if you visit in a browser.

Bug or feature?

[evanjbowling]

I was able to reproduce this issue as well (bower --version 1.7.9).

Steps

1. bower init
2. bower install https://npmcdn.com/[email protected]/bower.zip --save
3. Confirmed that "https://npmcdn.com/[email protected]/bower.zip#^0.9.3" is recorded in the bower.json
4. Ran bower install
5. Observed bower ENORESTARGET URL sources can't resolve targets

Possible solution

Looks like the UrlResolver throws an error if the target specified is not "*". By removing this constraint I was able to still successfully run bower install

i.e. remove

    // If target was specified, error out
    if (this._target !== '*') {
        throw createError('URL sources can\'t resolve targets', 'ENORESTARGET');
    }

Does anyone know why we were throwing this error?

[benmann]

I think this was never intended as the error itself reads. If you resolve via URL you were not supposed to specify a version. For example installing a zip archive from dropbox or similar not versioned storage is what the URL resolver is for. However I'm pretty sure this still worked for GitHub URLs, as a different resolver would kick in. I'm also curious why the people behind Headroom.js are making this change in the first place. Having the project on GH and then installing via URL seems a little strange 😀

[sheerun]

Indeed, you can't specify versions when you download dependencies via simple url.

[WickyNilliams]

Hey. I'm the author of headroom.js

I believe this is a bug with bower. The URL itself is valid, npmcdn has no problem responding to the URL, but bower chokes on it.

It is bower that adds the hash fragment to the end of the URL, which seems to be causing the problems.

The URL specifies the version number, but that shouldn't have any effect on bower. It's just a URL after all, nothing special about it.

My reasoning for going with this approach is because I do not want build artefacts committed to my repos. Build artefacts cause endless confusion in PRs, because people accidentally submit them as PRs. Then I have to go through a cycle of back and forth explaining why they shouldn't be committed and how to remove them. Creating extra work for me, and additional friction for contributors.

[lenybernard]

Hey, I agree with you @WickyNilliams, it's too bad for bower.
I have a workaround for you which is better than nothing. Instead of specifying a tag, you can give the zipball link.

For example:

    "dependencies": {
        "headroom": "https://github.com/WickyNilliams/headroom.js/archive/v0.9.3.zip"
    }

It won't evolve but you'll be able to set the wanted version.
:(