Suggestion: In composer outdated, mark the packages coming from my own composer.json

[ThomasLandauer]

When looking at the output of composer outdated, I'm always having the same question:

• Is the package listed in my own composer.json (which means I can update it myself right away)?
• Or is it required by some other package (which means I can't do anything about it immediately)?

So to make this more obvious, I'm suggesting to somehow "mark" the packages which are coming directly from composer.json (maybe with an asterisk, or however...)

[Seldaek]

Is the package listed in my own composer.json

You can filter that with --direct, but maybe we could highlight them somehow.

[Seldaek]

Note that it being a direct dependency does not however really mean that it's fully under your control, there might be a dependency on it from one of your dependencies which prevents an update.

[Seldaek]

One idea worth investigating would be to split the list in two sections, things only required by composer.json and then the rest. It might be more readable than a *.

[ThomasLandauer]

there might be a dependency on it from one of your dependencies which prevents an update.

Yes, but that other dependency might be in my composer.json too. Example: Bumping one Symfony package from 5.4 to 6.0 doesn't work, but bumping them all does. So listing them as "not upgradeable" gives the false impression that I can't do anything about it.
So I still suggest to mark them as "upgradeable", with the rationale: "It's worth trying. If it doesn't work out, the error message will guide you anyway."

Two lists: Yeah sure, the * was just a quick idea! Some more: using a different color; using some indentation...
Actually: You know what would be even better? Replacing the last column (=description) with the source:

• Either composer.json if it's a direct requirement
• Or the imploded list of package names that require it

So integrating the basics of composer why into composer outdated. As I already said in some other issue, most descriptions are quite useless, and this is especially true when I just want to see which packages are outdated.

[stof]

The split in 2 lists would not be upgradable vs not upgradable, as computing that would actually require trying to do the update

[Seldaek]

See #10779