bower/bower — pull request #1282 by Nu11Terminator (2014-05-06 19:02:49+00:00)
Title: Very rough prototype for "conservative" update mode

Hi there,

I've put together a solution for my own purposes that allows bower to update in a "conservative" approach, so that it starts with the latest version of each package and works its way backwards until it finds a compatible combination of all packages in a bower.json file and their dependencies. This would allow someone to start with bower.json, run "bower install -c" and expect that the result is runnable. My personal use case for this to periodically run "bower update -c" on occasion during development and receive newer compatible updates as they come.

I want to say up front that, even if you decide this feature is handy enough to incorporate into bower, I realize there are still some issues that would still need to be addressed before this pull request could be accepted.

1) I've kept my code segregated into a separate lib/fullResolve.js file, inserted my logic into Project's analyze step. It's just a function with a 'this' that is bound to the Project. I think I could factor this into some sort of TreeWalker or ResolutionStrategy type that uses a Repository as a dependency.

2) I've disabled the automatic saving of bower.json (because I update the json object, which changes its hash value). I tried may different approaches of specifying a list of specific versions to the system, but bower always took later versions of packages than what I specified, and those versions weren't compatible with the installation as a whole. Strangely, I even tried an experiment in which I created a bower.json with all hardcoded, specific version numbers, ran the unmodified bower tool against it, and it did the same thing.

3) I couldn't get the log system to work. I'm sure it was my own lack of understanding, but it didn't seem to be initialized by the time my code ran. Instead, I have a duct-tape version of verbose logging that simply checks config.verbose and calls console.log. I'm sure I can figure this out myself, so please just disregard the "verbose" function I've added to fullResolve.js.

4) Once the code is refactored, I'll need to add unit tests.

Sorry if this isn't the best way to submit an idea that isn't completely fleshed out. I mainly just wanted to be able to provide a working set of code that successfully behaves the way I have described. If this feature is something you'd be interested in folding in, I could use some direction in how to integrate with the current code base. For example, should this type of logic go into Project or into Manager? Should their be a new type, like "ResolutionStrategy" to handle how selection occurs?

Any feedback would be appreciated. If there is interest by the team, I'm sure I can afford to sink more time into this.

Thanks.