Recently I decided to do a Mix Task to run some script files in the project. Being my first Mix Task, I followed a tutorial and got the following structure:
defmodule Mix.Tasks.Deploy do
use Mix.Task
@shortdoc "Compiles the app for PROD and starts a Rolling Release."
def run(_) do
#do really awesome stuff here
end
Problem
We are using credo and one of the warnings it gives me is the following:
┃ [D] Nested modules could be aliased at the top of the invoking module.
┃ lib/mix/tasks/deploy.ex:21:19 #(Mix.Tasks.Deploy.run)
Now, I checked the project dos referring to this error:
It sounds like you are calling a function like this:
defmodule Mix.Tasks.Deploy do
use Mix.Task
def run(_) do
# doing really cool stuff
# ...
Comeonin.Argon2.hashpwsalt("some password")
# ...
# more cool stuff
end
end
What credo is suggesting is to do something like this:
defmodule Mix.Tasks.Deploy do
use Mix.Task
alias Comeonin.Argon2
def run(_) do
# best programming you have ever seen
# ...
Argon2.hashpwsalt("bestpassword")
# ...
# more cool programming
end
end
So, credo is complaining that you are calling a function with nested module names, Comeonin.Argon2.hashpwsalt/1, for example. It wants you to call a function with a singular module name, like Argon2.hashpwsalt/1. So you can use alias for this purpose. The cool think about alias is that it is lexically scoped. This means you can use it within a function if you need.
Although do note that the “[D] ” part of the “warning” indicates that is is a very low severity “issue”, really more of a suggestion. I don’t think it’s idiomatic Elixir code to alias every single module you reference. In fact I tend to only alias modules that are used very often in the module, leaving a full module reference to indicate that longer module reference is not used/tied as deeply with the rest of the containing module (sorry this is a little hard to follow).
I do the same, I actually rarely use alias. In fact, I tend not to like using alias often, because I like to know the origin of the functions I am calling. Right or wrong, that is just personal preference on my part though.
I alias out parts that are ‘obvious’, like the main namespace at the very least, sometimes down to the specific function call (import) if perfectly obvious, otherwise I keep a name mapping or 2 or 3 worth of dots.
I alias a lot because it is easy to see when I use too many aliases.
I see this as a code smell that is telling me I have too many dependencies.
But I agree that this warning is a bit too pedantic and shouldn’t give a non-zero return.
Credo forcing aliasing of hex dependencies pushed me to bring this old thread to life
I think the main thing is to make sure you don’t lose the ability to search (grep) for the full module name and have all the places where it is used to show up:
defmodule My.Module.Name do
end
defmodule My.OtherModule.Name do
end
defmodule Some.Other do
# This is a bad alias because if I search for `My.Module.Name` this wont show up
alias My.Module
# This is fine, but not always neccessary - you can use the fully qualified name
alias My.Module.Other
# In the case of conflicting final names, this is preferred, because I can still search
# for `My.OtherModule.Name` and have this show up.
alias My.OtherModule.Name, as: OtherModuleName
end
Nested modules could be aliased at the top of the invoking module.
if you need.
” part of the “warning” indicates that is is a very low severity “issue”, really more of a suggestion. I don’t think it’s idiomatic Elixir code to alias every single module you reference. In fact I tend to only alias modules that are used very often in the module, leaving a full module reference to indicate that longer module reference is not used/tied as deeply with the rest of the containing module (sorry this is a little hard to follow).
