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

install with force-latest should not update bower.json #2344

Closed

Comments

@himdel
Copy link

himdel commented Aug 18, 2016

Output of bower -v && npm -v && node -v:

1.7.9
3.10.5
v6.0.0

Steps to reproduce the issue:

  1. Have a conflict that needs a resolution
  2. Run bower install -F
  3. see that bower.json got changed

Describe the results you received:

Bower automatically picks a sane resolution (good), but it stores that resolution in bower.json (bad).
There seems no way to prevent bower from saving that resolution.

Describe the results you expected:

I would expect bower to save the resolution only when --save (or something similar) is used together with --force-latest, not by default.

Or, a way to prevent that behaviour.

Additional information:

Looks like it was introduced in #862 , to fix #861, but #861 does mention expecting that behaviour only with save: true.

The reason I'm asking for this is that we're always using bower install -F in our scripts, since most of the developers are not frontend developers and can't be expected to know better than bower (also, CI). And this works just fine... Except then you get a conflict, and suddenly everybody starts commiting resolutions which are unnecessary since you'll mostly get a sane one using -F anyway, and then somebody needs to clean it up when that resolution becomes obsolete and actively wrong..

himdel added a commit to himdel/bower that referenced this issue Aug 18, 2016
…ns is used

Closes bower#2344

Without this, there's no way to prevent --force-latest from modifying bower.json when it resolves a conflict.
This adds a --dont-save-resolutions to prevent that.

Not sure this is the best way, but it's the compatible way :).

Also, I have no idea how to get at the parsed options in Manager, directly looking at cooked argv is probably not the correct way..
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment