Inconsistently named installs with bower

[wheresrhys]

I’m not sure how new or how big a problem this is, but as of yesterday I’ve noticed the following behaviour

$ bower install ftdomdelegate
bower cached        https://github.com/ftlabs/ftdomdelegate.git#2.0.3
bower validate      2.0.3 against https://github.com/ftlabs/ftdomdelegate.git#*
bower install       dom-delegate#2.0.3

dom-delegate#2.0.3 bower_components/dom-delegate

which means it gets installed in the bower_components/dom-delegate directory, and must be required as require('dom-delegate’). However, if ftdomdelegate is installed implicitly (e.g. o-share is installed, and ftdomdelegate is a subdependency) then it is installed in bower_components/ftdomdelegate.

a) Is this a bower bug? b) To avoid the bug and to make the naming of this component more comprehensible should this repo be cloned to dom-delegate for backwards name compatibility, and bower.json in this repo be renamed ftdomdelegate

using bower@1.6.8

[apaleslimghost]

Looks like the package was registered in Bower as dom-delegate. I've no idea how bower install ftdomdelegate was finding it. I've registered ftdomdelegate, and I'll update the name in bower.json.

[apaleslimghost]

Findings:

1. Older versions of Bower (circa 1.3) put bower install ftdomdelegate in bower_components/ftdomdelegate. Recent versions put it in bower_components/dom-delegate (the name from bower.json.
2. I have no idea how Bower's resolving ftdomdelegate; it's not registered in that name.
3. Packages shouldn't be doing bower install --save ftdomdelegate, because the package shouldn't exist under that name.

2 seems like a Bower issue. 3 is something we should fix in o-share etc.

[wheresrhys]

2 - ftdomdelegate is in the origami regsitry 3 - we decided that within ft ftdomdelegate should be the canonical name (see the issue linked to above). Unfortunately we need to support dom-delegate too as that's the name it was publicly published as first

On 5 January 2016 at 12:04, Matt Brennan notifications@github.com wrote:

Findings:

1. Older versions of Bower (circa 1.3) put bower install ftdomdelegate in bower_components/ftdomdelegate. Recent versions put it in bower_components/dom-delegate (the name from bower.json.
2. I have no idea how Bower's resolving ftdomdelegate; it's not registered in that name.
3. Packages shouldn't be doing bower install --save ftdomdelegate, because the package shouldn't exist under that name.

2 seems like a Bower issue. 3 is something we should fix in o-share etc.

— Reply to this email directly or view it on GitHub https://github.com/ftlabs/ftdomdelegate/issues/77#issuecomment-168982478 .

---

This email was sent by a company owned by Financial Times Group Limited ("FT Group http://aboutus.ft.com/corporate-information/#axzz3rajCSIAt"), registered office at Number One Southwark Bridge, London SE1 9HL.
Registered in England and Wales with company number 879531. This e-mail may contain confidential information. If you are not the intended recipient, please notify the sender immediately, delete all copies and do not distribute it further. It could also contain personal views which are not necessarily those of the FT Group. We may monitor outgoing or incoming emails as permitted by law.

[apaleslimghost]

Aha, gotcha. So at a guess it's not the repo name but the fact that the name in o-share's dependencies is different to the name in bower.json. I'm putting together a test case to verify.

[apaleslimghost]

Test case: https://github.com/quarterto/quartertobowertest-dep. It's definitely the difference between the dependencies key and the bower.json name. It's worth noting that bower install --save ftdomdelegate would add it to dependencies as an alias to dom-delegate:

"dependencies": {
  "dom-delegate": "ftdomdelegate#^2.0.0"
}

I'll report to Bower.

[notlee]

v3 renames to ftdomdelegate