Option to skip incompatible dependency updates

[lukemovement]

Would it be possible to have an option to skip dependencies that cause issues? I want to preform a general update to my dependencies and find that I am regularly having to restart the process, after appending the dependency in question to the excluded list, due to that dependency failing the tests.

[debuglevel]

That would be nice. Something like a "do what is possible by retrying the other packages until you really cannot achieve anything more"-option.

[pilotpirxie]

Hi, great idea! I guess it would allow developers to update "to the latest possible dependency state" within the same codebase. How exactly do you see this working from the DX perspective? If an update causes problems and fails the tests, should we roll back to the previous stable version of that dependency and not try to update it again forever? This would be the simplest approach.

Alternatively, we could temporarily skip the problematic update, update other dependencies first, and then try again to update the failing one. However, from my experience, this might only help with a few updates and can make the process much longer (plenty of install and test runs).

I would go with the first option because it's simpler, more intuitive to understand how it works and likely to cause fewer issues. Let me know what you think :)

[debuglevel]

Hi, great idea! I guess it would allow developers to update "to the latest possible dependency state" within the same codebase. How exactly do you see this working from the DX perspective? If an update causes problems and fails the tests, should we roll back to the previous stable version of that dependency and not try to update it again forever? This would be the simplest approach.

Alternatively, we could temporarily skip the problematic update, update other dependencies first, and then try again to update the failing one. However, from my experience, this might only help with a few updates and can make the process much longer (plenty of install and test runs).

I thought about that too.
But to be honest: Right now I'm just adding those packages to --exclude (which is basically the first option 😀) and hope my future self will figure out what to do with them.

Would it be useful if a --exclude-file is used by default and those packages are written into it? This way a subsequent run (if something crashes or I hit CTRL+C) would not try these packages again -- and there would be already a list of packages which require some manual investigation.

[kjrocker]

I've been using the library recently and having similiar thoughts.

I frequently find that one update breaks the codebase, but then the solution is to actually upgrade further manually. So a break in version 1.12 will be fixed by manually skipping to 1.14.

It would be very cool if it could skip a failing version, but still try the next version.

This could apply to major/minor versions as well. Sometimes there are a few updates to the minor version after a new major version has been released. I want to skip the major version, but still get any minor-version security updates.

If we have some ideas on this, I volunteer to take some time to look at it.

My suggestion would be a few new CLI options. I'm bad at names, but this is the gist.

--skip-version = When an update fails, will try the _next_ update to that package instead
--skip-package = When an update fails, will permanently exclude that package
--skip-major-version = Skip major version updates for all packages