Closed scohen closed 1 month ago
Nice!
I don't have time to dig in at the moment, but a couple quick thoughts:
In my opinion, an extra newline should be added after module-level aliases unless it's being added to an existing "block" of aliases. For example:
defmodule Foo do
alias Some.Newly.Added.Thing
def example do
Thing
end
end
defmodule Bar do
alias AAA.BBB.CCC
alias Some.Newly.Added.Thing # no newline added because another alias was already present
def example do
Thing
end
end
Where does the new alias get added when there are other module-level forms? like @moduledoc
, defstruct
, etc. IMO: Should be top of the module, but below @moduledoc
with an extra newline.
defmodule Foo do
@moduledoc """
Module doc for Foo
"""
alias Some.Newly.Added.Thing
def example do
Thing
end
end
@zachallaun I actually think the newline should be added to the first condition to keep the existing formatting, agreed about where to place an initial alias, I'll write some tests for that.
When coding, it is more convenient to type what you mean, and then come back later and clean up things like aliases. This change implements a code action that understands your current editing context and adds aliases as you type. It finds suggestions using our fuzzy matcher (though it has a bit stricter fuzziness), then provides code actions for each suggestion.
It will fix the following alias types:
Foo.Bar.Baz|
will result in aliases for modules similar toBaz
%Foo.Bar.Baz|{}
will result in aliases similar toBaz
, but only those that have structs defined in themFoo.Bar.baz.function|
will result in aliases for modules with a function with a name similar tofunction
This PR also pulled a bunch of common code out of
orgaize_aliases
and moved it to a code mod file, which resulted inorganize_aliases
having very little code left in it.Fixes #716