Alias hex.outdated as deps.outdated?

I’m not sure if this is the best place to ask this, but would it make sense to alias mix hex.outdated as mix deps.outdated? It always trips me up that I need to run mix hex.outdated to see outdated dependencies, but to update them, I need to run mix deps.update [package]

Also, when running mix hex.outdated, the description at the bottom would be even more helpful if it showed the command to update. I know the command now, but when I was learning, I had to go searching for that command.

1 Like

would it make sense to alias mix hex.outdated as mix deps.outdated?

You can do that per project, see

Right now, it doesn’t make sense for Mix to have deps.outdated task because only Hex provides that functionality anyway (e.g. not git dependencies and for path dependencies that doesn’t even make sense).
However, if there is something like Mix.SCM.outdated? callback (that Hex.SCM and Mix.SCM.Git implements) that would then be more feasible. cc @ericmj

The problem is that the only SCM that can implement it is Hex. We don’t know if git or path dependencies are outdated.

Sure, for path deps it doesn’t make sense (as far as I understand they’re always up to date). For git I thought we could essentially do git fetch (into temp dir, or fetch just mix.exs into tmp file) to compare versions. I think that should work as long as dep is pinned to a branch (and not to a tag which virtually never changes)

I don’t understand how it could work with git, do we fetch all tags, open up mix.exs and look at the project version? This does not seem viable.

A git dep in mix.exs can be either pinned to a ref/tag (which won’t/shouldn’t be outdated), a branch, or nothing (so default branch). So if it’s a branch we need to look at the tip of the upstream branch to find the latest version. I agree that manually looking at mix.exs to find the latest version isn’t great. No need to pull tags because we don’t care about them, we only care about deps pinned to branches - If we would care about tags then updating to a newer tag would require user to manually change mix.exs to pin to that tag.

Anyhow, I’ll do some more research and will do a proper proposal if that’d still look reasonable enough.

They would work quite differently since Hex looks at all available versions and Git only looks at updates to the current branch. Hex also informs you if you need to update the version requirement which we can’t do for Git. Since they work so differently I’m not sure how they would fit in the same UI.