Is there an upgrade Guide for Phoenix 1.8?

Phoenix Forum Questions / Help
,
1

There used to be a gist with upgrade instructions for each new Phoenix version. For example here Phoenix 1.7.0 released: Built-in Tailwind, Verified Routes, LiveView Streams, and what's next - Phoenix Blog it is linked at the bottom under “As always, step-by-step upgrade guides are there to take your existing 1.6.x apps up to 1.7.“ (phoenix-1.6.x-1.7-upgrade.md · GitHub).

With 1.8 I see no such link here Phoenix 1.8.0 released! - Phoenix Blog in search only this article shows up Migrate to Phoenix 1.8 (rc version) guide - DEV Community but it’s not official guide and it uses RC, not the released version. I can still do the minimum necessary changes using changelog ( Changelog for v1.8 — Phoenix v1.8.1 ) but the guides helped with optional changes - seing what needs to be done saved time. Are we left with changelog and diffs from now on or am I missing something?

7 Likes
2

I ended up pretty much where you’re describing, and ended up working piece-by-piece through a diff to get things working.

It was not a particularly enjoyable upgrade, but it was nice to be able to rip out the few remaining npm dependencies in the project that I upgraded (type definitions and daisyUI v4).

2 Likes
3

I recently upgraded a couple of apps and literally all I had to change was one line in mix.exs due to this PR. A warning was provided telling me exactly what to change but I do think this should have been in the changelog as well (it wasn’t as far as I saw).

I’m not exactly sure what changes you guys have been making but I certainly found it quite painless!

Incidentally I also decided to finally upgrade to Bandit, which I had been avoiding, and it turned out that is also literally a one-line change. Shoutout to the dev teams for that one, I’m sure it wasn’t easy to make it that easy :slight_smile:

1 Like
4

If you don’t mind sharing – what is the one-line change? I want to move to Phoenix 1.8 but just can’t muster the motivation and energy to properly read instructions.

EDIT: Oh, I misread. I am guessing it’s just this then?

      def project do
        [
          ...,
+         listeners: [Phoenix.CodeReloader]
        ]
2 Likes
5

Yes, just that line. If you actually upgrade it will give you a warning telling you exactly what to do.

I was just caught off-guard because I always read the changelog first and I didn’t see it there. A quick git blame on the template and I pieced it together :slight_smile:

None of the other 1.8 or LV 1.1 changes seemed to have any effect on my apps at all. I guess those above are also trying to upgrade to DaisyUI etc? I don’t use tailwind and I bring my own core components, so I can safely ignore all of that business.

Even if you use Tailwind your existing setup will still work, though.

1 Like
6

I’m not exactly sure what changes you guys have been making but I certainly found it quite painless!

In my original post I wrote that:

I can still do the minimum necessary changes using changelog ( Changelog for v1.8 — Phoenix v1.8.1 ) but the guides helped with optional changes - seing what needs to be done saved time.

So yes, making things work is easy, seing the optional changes is not.

I guess I must elaborate on my situation: we have more than a couple projects that use Phoenix, they were started at different points of time with different Phoenix versions and we try to keep them up to date including many (but not all) optional changes. If we don’t, we either miss on the new stuff or have a lot of unnecessary context switching when doing different projects.

When I read upgrade guides, I was able to see what exactly I must do to move to some new thing and then I decided to do or not do that. Without a guide I have to infer that from diffs which is still possible but more time consuming and less reliable, so I will probably end up with only doing necessary changes.

I guess those above are also trying to upgrade to DaisyUI etc

I’m still thinking about that, but yes, the diff has some frontend changes which I consider, but frontend people will get the last word there. It is not just about Tailwind (or JS) related stuff. For example the new Phoenix uses unified layouts which look good to me, but moving to them in the existing project is not desctibed and the change is optional, so things will just keep working. It’s not a problem now, but in a couple years half of our projects might have root and app layout and the other half - just root, eventually we’d probably want to consolidate that anyway and I just like doing that right away during update where it’s easy, before starting to get those paper cuts. Otherwise it’s basically a soft version of tech debt

I am guessing it’s just this then?

@dimitarvp aside from adding listeners you also need compilers: [:phoenix_live_view] ++ Mix.compilers() if you move to newer LV, though this might be a change from 0.x.

1 Like
7

Okay, I see where you’re coming from. The 1.7 changes were more impactful (Verified Routes in particular) but I agree a quick guide for how to upgrade at least the layout stuff would be a good idea.

The Phoenix team have maintained that the frontend stuff (Tailwind/DaisyUI/core_components) is only meant to be a starter kit so I think they are less interested in providing upgrade instructions for those.

This change is indeed from LV 1.1. It was actually mentioned in the changelog, but apparently I just missed it! Leaving it out didn’t break anything for me, though. It’s probably for colocated JS which I have yet to try out.

2 Likes
8

Can confirm. It’s just needed for colocated JS atm.

3 Likes