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.
would it make sense to alias mix hex.outdated as mix deps.outdated?
You can do that per project, see https://hexdocs.pm/mix/Mix.html#module-aliases.
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
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.