Extra "lib" folder on npm install

[kflorence]

This just started happening on our build server and I was able to reproduce it locally with bower@1.7.5. There seems to be an extra "lib" folder in the node_modules folder now, so for example the bin is located at lib/bin/bower instead of bin/bower -- unsure if this is a bug or not, but lib/lib seems odd.

[sheerun]

It's on purpose. Is it an issue for you?

[bornholtz]

This breaks https://github.com/eirslett/frontend-maven-plugin

[kflorence]

It was an issue, but I've switched from using hardcoded bin path to using node_module/.bin/bower which fixes the problem for me. Just be aware that changing the bin path is not backwards compatible so it may break things for other people as well.

[lucy5533]

Also breaks https://www.npmjs.com/package/grunt-bower-install-simple

[vijayk]

Yes It break zeppelin as well.
We are using maven frontend plugin and it is expecting bower binary at "node_modules/bower/bin/bower" after npm install bower.

Please see this: https://issues.apache.org/jira/browse/ZEPPELIN-634

We have moved to bower:1.7.2 to fix zeppelin issue.

[sheerun]

I'll create an alias for binary where it was..

[vijayk]

Thanks a lot @sheerun, it would definitely solve our purpose.

[bentolor]

Having a deprecation warning in a wrapper file for transition and not changing this in a point release in the future would be appreciated.

[derTobsch]

how could it be that a bugfix upgrade breaks so much stuff? This could be a hint that we should not use bower anymore...

[sheerun]

It's breaking for you because you're using bower binaries directly, instead using npm aliases. If you used binaries from npm bin --global or npm bin the path wouldn't change.

I understand this change affects people using bower this way, so I will create an alias anyway.

[bentolor]

@sheerun Yes, but nobody told us or others.

For example the people at Atlassian are using exactly this path as Default on integrating Bower as task into their Bamboo CI. So all Bamboo CI Plans using Bower are failing right now. Further more I'd have never been able to have understand what it is supposed to be without the fast feedback here (big plus!).

General rule thumb of rule: If you have ever exposed anything in your libraries it will eventually get used and it will eventually be really hard to change. Careless how it is supposed to be right.

I think the best solution would be:

• write a wrapper which spills out 3 annoying warning message that everbody should use the new location
• remove that wrapper in the next major release.

[derTobsch]

@bentolor 👍

[sheerun]

We're really careful to not introduce any backward-incompatibilities and the process is exactly like you describe for features that are documented to be public. For these that aren't, we release patches as soon as possible.

Besides, we can't notify you not use bower binaries directly, because there's no way to detect it.

I've released bower 1.7.6 that should fix your issue.

[bentolor]

Thank you @sheerun for the fast fix!

[derTobsch]

Thanks!

[derTobsch]

"Also breaks https://www.npmjs.com/package/grunt-bower-install-simple"

...but still failing, because "bower/lib/renderers/StandardRenderer" is missing.

[benmann]

@derTobsch basically this: #2160. It also explains why the lib in the first place..

[sheerun]

Great... I can't assume people are not depending on any random file in bower. I'll try to figure out how to preserve all the paths while still embedding node_modules.. @derTobsch What package is failing for you?

[derTobsch]

@sheerun https://www.npmjs.com/package/grunt-bower-install-simple, this does depend on "bower/lib/renderers/StandardRenderer". I added a pull request for that module and informed the developers. Let's see what they will do. I also forked that package and will use my branch with the fix until they fix it.

[sheerun]

@derTobsch I've released bower 1.7.7 with almost all paths back at their places.

[derTobsch]

@sheerun that fixed our problems. thanks