outdated: option to check only direct/explicit dependencies?

[ivan-kolmychek]

We're running bundle outdated automatically against our code base to find and report any outdated dependency, let's say, as a part of the CI build.

To notice that there is a new version that's falling out of our version constraints specified, we also use --no-strict (it's unnecessary right now, ofc, but may be necessary later).

Some pretty useful gems, like pry or even actioncable, are depending on not-the-latest-version of some gems. For instance, at the time of the posting, running bundle outdated with pry 0.10.5 and actioncable 5.0.1 in project produces:

Outdated gems included in the bundle:
  * nio4r (newest 2.0.0, installed 1.2.1)
  * slop (newest 4.4.1, installed 3.6.0)

It would be nice to have a flag (like with --strict/--no-strict) to check only top-level/direct/explicit dependencies. This way the bundle check we use can be set up in two separate checks: 0) for direct dependencies, not strictly and 1) for all dependencies, strictly.

Is there anyone else also interested in this feature?

[ivan-kolmychek]

I think I should also share the workaround that we use right now, it's based on the fact that bundle outdated accepts the list of gems to check and, in our case, it is called from the shell script.

So, instead of the flag, we can launch first check like this:

cat Gemfile \
  | grep -v '^#' \
  | grep gem \
  | grep -o "[\'\"][a-z0-9_-]*[\'\"]" \
  | grep -o "[a-z0-9_-]*" \
  | xargs bundle outdated

The second check ("for all dependencies strictly") is done via regular bundle outdated --strict ofc.

[LilyReile]

Seconding this feature request. I always run throughbundle outdated before upgrading rails and it would be nice to have a switch that shows only the actionable items.

[jclif]

Would definitely love to see this feature as well; we are, similarly, running bundle outdated at the CI level to signal warnings on branches.

[grv87]

If you mean, ignore version constraints specified in my Gemfile but still respect constraints specified in gems' metadata, then +1

My current workaround is to manually make temporary clone of repository, remove version constraints from Gemfile. run bundle update and see what is updated.

[ivan-kolmychek]

@grv87 in a way.

I mean limit the check to only your direct dependencies, completely ignoring their own dependencies.

As an example, if you have a gems A, B and C in your Gemfile, and they depend on some other gems that you haven't specified, like X, Y and Z, with requested flag it would check only A, B and C.

This way you can combine it with already existing flags to customize the checks to suit your particular need.

For example, if you want to NOT ignore the version contstraints specified in Gemfile, you can use the --strict flag, which, according to documentation:

Only list newer versions allowed by your Gemfile requirements.

Also, check out the workaround script I've posted, I think you can customize it for your needs and thus avoid making a copy of repo each time you need that.

[grv87]

@ivan-kolmychek, when you say

completely ignoring their own dependencies

what do you mean? Should Bundler still respect their dependencies, just exclude them from output?

Suppose that:

1. Your Gemfile has

   gem 'A', '~> 1.0'
   gem 'B', '~> 1.0'
   

2. There is a newer version of gem B 2.0
3. Gem A 1.0 depends (directly or indirectly) on gem B 1.0

Should Bundler report that gem B is outdated? I believe, no.

Another case is when gem A 1.0 depends on gem C 1.0, and gem B 2.0 depends on C 2.0.

I'm mostly under Windows, so no Shell scripts.

[ivan-kolmychek]

Should Bundler still respect their dependencies, just exclude them from output?

I think it really depends on your use-case.
We use this "top-level" non-strict outdated check as a way to detect that we have outdated top-level gems, regardless of why exactly are they outdated.

Even if A depends on B 1.0 when there is a newer version, B will not magically become up to date just because of that.

Should Bundler report that gem B is outdated?

Recently we've hit almost exactly the situation you've described - one of the gems we use depended on old version of faraday, but we also use faraday, so "direct update" is not possible.

Which means that we needed to evaluate what our options are (including submitting PR to update the version constraints, forking the gem, replacing faraday with something else in our code, ditching out that dependency if it's not critical, adding faraday to exceptions, etc. etc).

What's the most optimal course of action in similar situation can depend on variety of factors, like what gems are those A and B, how important they are for your project, how wide are they used, etc. etc. So I believe this should be evaluated on case-to-case base, when the situation arises.

But important part is, the notification from check gives you the chance to do that.

I believe, no

If you want it to actually respect dependencies, I think that some kind of an additional flag can also be used, like the --strict or even some new one.

I'm mostly under Windows, so no Shell scripts.

That's actually fine, you can still use shell scripts under the Windows in a variety of ways:

• first of all, bash is bundled with Git for Windows, so you probably already have it installed on your machine anyway if you're using Git (official download page for Windows uses links to dists from "Git for Windows")
• and even if you don't use Git for Windows, there are Cygwin, that Ubuntu-on-Windows-10 initiative and Docker for Windows, all of them run bash

(I personally used Cygwin on a few occasions when I was limited to Windows machine by circumstances and it worked pretty well for me.)

Or you can even write the analog in PowerShell and share it here, it's probably not hard.

[grv87]

@ivan-kolmychek, ok. So we have two different use cases and require two different solutions.
I won't open new issue for now, until this is resolved.

I know about Git bash and Cygwin and gnuwin32 and so on. Probably I'm lazy enough to go this way for this specific task :) Let's stop this discussion as off-topic.

[Simbul]

I also would be interested in this. I'm sure there's a use case somewhere, but I'm struggling to see what's the benefit of bundle outdated returning non-actionable results.

I can see @segiddins marked this as a feature request back in January. Forgive my ignorance, but I couldn't find an answer in the contribution guide: is there a process after that, or is it simply a case of "it's done when it's done"?

[segiddins]

@Simbul that generally means "seems like a cool idea, we'd be happy to merge a PR adding it"

[peret]

I would also love to see this feature added and took the liberty to prepare a PR!

[grzuy]

For what is worth, as a sort of workaround, I currently use bundle outdated --groups and ignore the gems listed under ==== Without group ====.