The future of upgrading phoenix / liveview apps with generated code

I’m really interested in the future of maintaining phoenix apps given the new practice of dumping generated code into a project versus separating things out as packages (something I think I love).

For example the phx.gen.auth (something that should never have to change, as José eloquently explained a while back when he wrote it). But for core_components I got bit pretty bad; all the form function components were re-written and the new generators require the updates to work. So now I have 20 generated routes (mix that work but any new generation will fail. My only recourse was to re-generate a brand new project and diff the core_components and carefully bring over the changes (since I modified the tailwind classes; something that feels reasonable). And even then, I had problems because it meant all my existing routes were broken, so I had to go back and re-write all of the live_views to handle things the new way. (I should note, I love the changes, big props to the change).

That said, there was no change log explaining it, upgrade path, etc…

Curious if I missed something or if others have thoughts on how we can improve this moving forward so we can continue to make phoenix + live view the best web development experience out there.


Yeah, there is a delicate balance for generated code vs. a library, where the former requires a higher maintenance cost, in that it’s not as easy for a developer inexperienced or not to increment a version number.

And I like your point about even when some generated code is not meant to change; from my experience, software changes over time.

1 Like

I’ve found PhoenixDiff very useful to see what’s changed between releases. It’s basically the diff versus a newly-generated app you described, only automated on a webpage.


Extremely helpful!! Yeah this is amazing and will help an awful lot for future upgrades.

1 Like