Package to remove unused aliases and imports

I got fed up with removing unused aliases manually so made a package for it: GitHub - KristerV/remove_unused_ex: Remove unused aliases and imports from Elixir code

Currently not yet released, because it seems strange to release a single function. What do you think, should I release it?

Notes

mix format plugin

initially started with making a plugin, but couldn’t figure out how to get the mix compile warnings in a fast way to the plugin. it seems that format plugins can in fact only run one function per file and running mix compile each time doesn’t make sense. and it wouldn’t be async anymore.

there is a workaround with aliases, so mix format would run the package just before the actual formatting. (see readme).

unexpected results

I never use the alias App.{One,Two,Three} format, so the package would remove the whole line even if only One is unused. If you guys deem this to be released I would figure out a solution for this.

Plus there’s probably other situations this fails. Haven’t really dug deep.

Should I release?

My worry is that releasing a single-function-package is just noise. And perhaps there’s a much better way of doing this in the first place? How do you currently remove unused aliases/imports?

The important file (only 47 lines) is here: lib/mix/tasks/remove_unused.ex if you want to check it out and comment.

2 Likes

I feel for something like this to be bullet-proof you’d want to use Sourceror to figure out what is unsed aliases and remove them (this would work for those who use {}).

This will likely come off as a “nobody asked you” type of statement but my solution to this is to call alias close to where they are used, ie, the same logic that is applied to setting variables. If a group of functions use the same alias I put it above the first one and it acts like a “section divider”. If only one function uses an alias I call alias right in the function itself. I find it helps a lot with readability—if I jump to a function in a module I’m unfamiliar with, I don’t have to them jump to the top figure out if it has dependencies. I also never feel the annoyance of forgetting to delete aliases because it’s usually within view. I did, however, feel your pain when I worked on a codebase where everything had to be aliased and always be at the top.

I’m not trying to preach or anything. To each their own, of course!

Also check out GitHub - hrzndhrn/recode: A linter with autocorrection and a refactoring tool. for other goodies.

3 Likes

do i understand corrently that you’re suggesting to analyze and edit AST so the rules i set are more precise and less fuzzy?

looks like recode (suggested by @dimitarvp) takes this approach (without fixing this particular problem).

not at all, in fact i asked how people solve this now. so exactly what i wanted. sounds like perhaps you’ve gotten pushback for this suggestion before?

interesting approach. i’ll think about this for my own processes. seems a bit messy in the end, but then again could actually reduce noise in a lot of situations i imagine.

hey nice! cool find. thanks. it’s interesting that it doesn’t do unused removal.

another tool i was suggested in private is elixir-styler - seems like they used Sourceror also, but dropped it due to speed. what do you think of this package, should I PR this one or recode? (if i ever get to that)

1 Like

That was my thinking. I had forgotten about recode as I haven’t tried it yet. A few months ago I was getting deep into syntax rewriting for a package I was working on, but then I got a new job (or rather a job, period) and haven’t been back to it yet.

Naw, I’ve just been feeling that my “hot take” to “attempted helpful solution” ratio has been off lately—it’s my own neurosis :sweat_smile: Really I default to not aliasing at all, except that there are non-insignificant number of situations where I do so it’s not a very useful thing to say in a forum reply. And of course it’s a personal taste kinda deal.

2 Likes