If your module A only depends on the struct of a module B, then we will only recompile A if the fields in the struct B change. But we always recompile the whole file the module is at. The beam of a module is always assembled as a unit.

A lot of it still comes from things like plugs and phoenix helpers, which are effectively fixed in the next Phoenix v1.4 version.

I like this talk and I think it’s good but it still doesn’t give me enough insight into our current compilation problems in a Phoenix project. We’ve ended up with a smaller version of the cited issue in the talk and recompilation currently takes 4-5 seconds which is enough to annoy us.

About the struct dependency bit; the speaker says this was changed. Does anyone know exactly how a struct dependency currently behaves in terms of recompilation? Does the Elixir compiler do analysis of struct-only changes or is it simply recompiling the module always regardless?

What I always wondered. If the compiler knows when to recompile which module, couldn’t that information be surfaced to the user? Like a “list me all modules, which are recompiled if module x changes (and why)”. mix xref is alreally nice, but even with all the knowledge about why and when modules depend on each other and need recompiling it’s still quite a lot of work to mitigate things in this space. I’ve had a few shots in a current project of mine and I while sometimes I found the spots to change I also had quite a few times, where I didn’t even find why modules would depend on each other even with the data xref produced. Maybe I should just try updating it to phoenix 1.4 and see how much it helps.