Thanks for the advice, I quickly found the culprit:

I had compile time dependencies from the router to two controllers. Because those controllers had a transitive run time dependency back to the router (redirects using route helpers) and from there to every other controller, changing any controller required the router to be recompiled.

The fix:

# change this:
get "/", MyApp.FooController, :index
# to this:
scope alias: MyApp do
  get "/", FooController, :show
end

simply because now the fully qualified module name of the controller it no longer present in the router.

Two other things I did/tried:

elixirc_options: [verbose: true]

in the project/0 callback of the MixFile, which made the effective dependency chain more obvious.

I also tried setting

config :phoenix, :plug_init_mode, :runtime

not only in dev mode, but in test mode as well, assuming that plug initialization would otherwise happen at compile time and that that would also be the case for the controllers being routed to (since they are plugs as well), but I was wrong here, the default :compile does not make all controllers compile time dependencies of the router.

I got tired of analyzing the output of mix xref so I wrote a thing… If you run into this problem please check out GitHub - schnittchen/why_did_recompile and help me improve it

Have you given DepViz a try?

I spoke about it at Code BEAM BR last year (in english): https://www.codebeambr.com/video/12

That is not quite accurate, an alias will only cause a run-time dependency. However, compile-time dependencies are transitive so if A->compile-time->B and B->run-time->C, then when C changes, A will need to be recompiled.

Was revisiting this a bit today and realized I forgot to mention that in addition to the sugggestions above we found adding GitHub - sasa1977/boundary: Manage and restrain cross-module dependencies in Elixir projects to be super helpful. It helped surface some poorly defined boundaries we had going on.

Not quite, you have that reversed. Now C has a compile-dependency on both A and B. The compile-time dep on B is direct, but the compile-time dep on A is transitive (because A depends on B at compile-time). This means that if the a.ex file or b.ex file is changed then c.ex needs to be recompiled (it generally doesn’t make too much difference but compilation dependencies are tracked on a per-file basis even though the dependencies are introduced on a per-module basis).

I’m pretty sure this is the blog post you are referring to:
https://medium.com/multiverse-tech/how-to-speed-up-your-elixir-compile-times-part-2-test-your-understanding-f6ff3de5eb5d

I highly highly recommend it to anyone struggling with recompilation in Elixir. It’s well worth the time to read through and test out the exercises.

Also a shameless plug for anyone that wants to narrow down where they might want to focus their recompilation efforts I wrote a tool called DepViz: