DejaVue

Big news in the Nuxt ecosystem. While you out there already know what has been announced - some of us didn't. Luckily, Daniel Roe, Head of the Nuxt team joins this DejaVue episode and discusses the highly anticipated "double trouble": Not one, but two major versions for Nuxt are on the horizon.
After over a year of delays, Daniel reveals the strategic decision to release Nuxt 4 in less than a month from now, followed by Nuxt 5 which will include the long-awaited Nitro 3 integration and significant Vite improvements.
The episode covers the smooth migration experience early adopters reported already, the philosophy behind careful breaking changes, and how the team plans to maintain a yearly major release cycle moving forward.

Enjoy the Episode!

Our Guest

Daniel Roe
Chapters

  • (00:00) - Welcome to DejaVue
  • (01:19) - The big topic
  • (02:41) - What are the release plans?
  • (06:47) - Two major versions soon?
  • (09:28) - Early adopters of compatibilityVersion 4
  • (11:56) - Depending on other dependencies and versions bumps
  • (13:45) - Is bumping the minimum Node version a breaking change?
  • (16:33) - A Quick Nitro TL;DR
  • (20:46) - Nitro in other frameworks
  • (25:20) - Why Nuxt 4 now?
  • (28:41) - LTS support Plans
  • (29:53) - Nuxt Bridge
  • (31:46) - Release Dates and skipping Nuxt 4 altogether
  • (33:14) - We need Release names!
  • (35:53) - Release Dates for Nuxt 4 and 5
  • (40:00) - Wrapping Up

Links and Resources


Your Hosts

Alexander Lichter


Michael Thiessen


---

Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators and Guests

Host
Alexander Lichter
DevRel @ VoidZero • Consultant • Nuxt team
Host
Michael Thiessen
Full-time Vue educator
Guest
Daniel Roe
Nuxt Team Lead and Independent Open Source Maintainer
Editor
Niki Brandner
Audio Engineer and Video Editor

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Michael Thiessen:

Welcome to DejaVue.

Alexander Lichter:

It's your favorite Vue podcast out there. And as usual, this episode, I'm with my lovely co host, Michael Thiessen. Michael, how are you doing?

Michael Thiessen:

I'm doing great. And I have no idea what's gonna happen this episode, So that's going to be lots of fun. Daniel Roe here is our surprise guest. So, yeah, looking forward to seeing what's going to come in the next bit.

Daniel Roe:

Hi, it's nice to be How much of a surprise was it to find me on the podcast? I feel like there would be other guests that were more surprising.

Alexander Lichter:

Like who?

Daniel Roe:

I feel if Joe Rogan appeared, there would be more

Michael Thiessen:

I would be shocked in many ways. Of all, did you get in contact with him? And

Alexander Lichter:

but why?

Daniel Roe:

There would be a lot of you would be asking a lot of questions. Let's be honest.

Alexander Lichter:

Okay. There there could have been a more surprising guest, but would there be more surprising guests in the Vue ecosystem? Possibly. Maybe. But topic wise, I think I mean, it depends when people watch or, like, listen to this.

Alexander Lichter:

It could be that they already like, okay. Yeah. It's all clear. But right now so from you, the listener, in the past, well, some of us have no idea what will happen in the future as we don't have a

Daniel Roe:

Most of us have no idea what will happen in the future. True.

Alexander Lichter:

Don't have a crystal ball that tells us.

Alexander Lichter:

But we're here for for one big topic actually, Daniel. Do you wanna give it away?

Daniel Roe:

Yes. We're talking about the release plans for Nuxt four and the release plans for Nuxt five.

Michael Thiessen:

Oh. Woah. Nuxt five.

Daniel Roe:

If you want to see someone's mind I don't know, Michael, we should have a reaction video. Michael should be like, This is what I'm thinking at this moment in time. Have you gone mad?

Michael Thiessen:

Well, I suspected that there that it might be Nuxt four related because I saw some, you know, some tweets and I was like, what is going on around MadVue? And then I I look to see what's the topic of Daniel's talk here? Oh, beyond Nuxt four. That's confusing because Nuxt four isn't even the present yet. So how can we talk about the the future?

Michael Thiessen:

And I was also confused because I had thought that there were some things around Nitro blocking the Nuxt four release, and so I hadn't seen any movement there.

Michael Thiessen:

So I was like, oh, I don't know. I don't know what's going on. And so I suspected that it might be around this, but, I still have questions.

Alexander Lichter:

Which questions? Bring them on.

Michael Thiessen:

Well, what are the release plans?

Daniel Roe:

That's a good start. Very specific. He's not asked anything about Nuxt five. I hinted at NUXT five, and Michael is just not picking up the bait. It's like, no.

Michael Thiessen:

I want to go chronologically.

Daniel Roe:

There's been enough hype. There's been enough hype. I want dates.

Alexander Lichter:

Don't give me two major versions. Just give me one release date. Yes.

Daniel Roe:

Exactly. So basically the idea is we have been over a year delayed from the original planned release date of Nuxt four. And that release date was based on a Nitro release date. So we planned to bundle the breaking changes for Nuxt as well as the breaking changes from Nitro into one version and release that. And for lots of good reasons, I should say that Alex and I and others on the Nuxt team are also on the Nitro team.

Daniel Roe:

So if we're looking at the causes for the delay, obviously we are involved in that. So for various good reasons, Nitro has been delayed, but always imminent at every step. So we've talked about it before and we've always decided let's wait for Nitro make one release. But I think it became apparent more and more that actually people have been trying out breaking changes for Nuxt with compatibility version four. People are shipping their apps with compatibility version four.

Daniel Roe:

For anybody who doesn't know that, that's a way of opting into the breaking changes with a flag in your configuration. And that's a bit terrifying to me as a maintainer because it's actually opting into unknown breaking changes. So if we ship a new plan to change for Nuxt four today and someone has this flag enabled, they will experience that. And so it's very important to test.

Alexander Lichter:

Every new version, I guess.

Daniel Roe:

Exactly, you have to treat it you're on the edge if you do this. But all of this means that basically there is a set of changes that people have been testing, people have been using for over a year, which represents our original plan for the next part of those breaking changes. And our plan was originally one major a year. So it shouldn't be too massive of a set of changes. So rather than continue to delay, could be out very soon.

Daniel Roe:

Nitro could be out within a month. But even if that's the case, I wouldn't like to ship all of those changes suddenly to the people who have already been testing the Nuxt changes for over a year, because suddenly they'll have new breaking changes, new things to investigate. What I would rather do is stabilize the current status quo and say, this is a major, let's be honest. People have been using it, people have been testing it for a year. We're going to ship it as Nuxt four, which brings with it promises of stability and promises of support.

Daniel Roe:

And then on the same release timetable that was happening originally, we'll ship Nuxt five, which will come with Nitro and will also come with some significant changes in terms of our Vite integration, which I've been planning anyway. So yes, two major versions, maybe two major versions in a very short space of time.

Michael Thiessen:

Okay. So basically if you've been opting into the compatibility, then in a way you've already been using Nuxt four and we're just making it official.

Daniel Roe:

Nuxt four was the friends we made along the way.

Michael Thiessen:

Yeah. Exactly.

Alexander Lichter:

So on that sense, I think it's a that's a good chance to remind us two episodes. We once had the year in review episode and also actually the hot takes for 2025 both of Daniel Roe. And he said it will be the year of Nuxt four. Or did I say that? In in any case, we talked a lot about their the Nuxt four and, well, future releases as well.

Alexander Lichter:

And same with episode number 13. Yeah. That's that's been a while. It was called the road to Nuxt four. And really happy to see that that road, well, we can see an end to it.

Alexander Lichter:

We can see that this is slowly but surely going to be Nuxt four at that point.

Alexander Lichter:

Now as you said, two major versions, do you have any worries about releasing two major versions? Do you feel that people could be afraid of, I don't know, flashbacks to other major version, let's say migrations, feel like, oh my God, we can never move on. Do you have any thoughts on that Daniel?

Daniel Roe:

So I think our aim was always with NUXT four to reassure people that major versions don't have to be scary. And we've spent so much time doing that, like carefully thinking about backwards compatibility flags, helping people opt in that And in fact, someone even said to me, Well, it's such a small change. Why even ship it as a major version? That was a very nice thing to say. True.

Daniel Roe:

It isn't. It's actually a lot of very significant changes, done hopefully in a way that feel small in terms of impact on end users projects. And so, I mean, I think, yeah, well, could people be worried about it? I hope it basically just reinforces the message that we're aiming to ship careful breaking changes. And in this case, we are going to be announcing it, telling people about it.

Daniel Roe:

And I'm not going to be continuing with the practice of shipping one major a month. I think we'll be reverting back to our plan of about one major version every year or so, which feels like a good rhythm for the changes that we end up having to make. We're not aiming to break people's projects, but there are bound to be changes that you need to make every now and then. That seems like a good rhythm for it.

Alexander Lichter:

Yeah. Also, in terms of, like, I don't know, certain dependencies going EOL, like, Node 18 is now EOL, that would be a breaking change to just say, like, okay. It's gone. And at least depending on who's here. But I think then once a year, especially set with like reasonable changes that ideally you could test out before if you want to because the compatibility version flag that will still continue to exist for future major versions, right?

Alexander Lichter:

You'll still be able to opt into certain breaking changes in the future.

Daniel Roe:

Exactly. So you can set it to five with release of Nuxt four. You can all be able to set it to compatibility version five and opt into any changes that we make between four and five. I think it's a really good strategy. And I know you've always been a big fan of Alex.

Alexander Lichter:

True that.

Daniel Roe:

Actually, who originally proposed compatibility version as an option, but whoever it was, it was a good choice and it could easily have been you.

Alexander Lichter:

I also I don't even remember. I only know the fine grained part that I was very keen on making sure that you can disable certain parts if your app can do everything except that one change and you want to work on that but opt into the rest. That's the only thing. And I also still think this is a very good practice for the future just so we have always the option to say, it's just this PR. I know exactly what I might have to take a look at my application and I can deal with that step by step.

Michael Thiessen:

From what I've seen online and different people in the community migrating to the the compatibility version of Nuxt four, it seems like it's been a lot smoother and people seem to have really good experiences with it. Like I haven't seen people complaining or upset. Maybe those people who have like the bigger, more difficult apps haven't tried yet to migrate over as much, but I think there's a lot of, especially with like the the different granular flags and stuff like that and the the code mods and other things like that. It it makes it a lot smoother to do that migration.

Daniel Roe:

Well, that is music to my ears. That's nice to hear. In general, I think the pattern has been reassuring. I was giving a workshop in Tampa last week. And as part of it, we migrated Elk to the Nuxt four compatibility version.

Daniel Roe:

And we did it in about fifteen minutes, it was a

Alexander Lichter:

Fifteen? One - five. That's very important to notice. It's not it's not a small app.

Daniel Roe:

It's a it's a big app. And actually, there's a lot of custom stuff that's been done with it. A lot of custom stuff. So it's not just renaming directories, but it was a pretty straightforward PR and actually fixed some bugs in the in the app.

Alexander Lichter:

Even better.

Daniel Roe:

Exactly. Even better. So that was nice to see. I really, really, really, really hope people aren't putting months well, certainly not months. I I hope I hope people don't even bother putting a weekend, you know, except if they have internal processes they have to follow.

Daniel Roe:

Like, I I I think that the migration should be pretty straightforward to make.

Alexander Lichter:

Also, if anyone's interested in the PR, link to that is in your show notes or description to really see that it could be done in in fifteen minutes. Also by you, not only by Daniel. I remember like when you when you told me that during a conference, like, I have to look it up. I would be so curious. And I checked and I was like, that all seemed very reasonable.

Alexander Lichter:

And with the migration guide, especially going through the steps, that will help a lot and having less moving pieces than in previous major versions as well.

Daniel Roe:

I think so. Exactly. Because part of the thing is if people upgrade to Nuxt four and they experience something like a behavior change, we can clearly identify it as a change that's happened in Nuxt. And then if they upgrade to version five, I think we can again we can clearly start looking at at Nitro. We'll be also needing that that opportunity to test the Nitro changes separately just because it's such a significant refactor of the server layer.

Daniel Roe:

I think it will be beneficial for Nitro as well as for Nuxt.

Alexander Lichter:

Good points there. In terms of Nitro, I remember that the original goal, maybe still case of Nitro is to be backwards compatible from a framework perspective. That while if you use NitroZen alone, of course, you might have to cater with some breaking changes that you have to change some things, switch things over. But from a framework level that might be able like, the Nuxt and also other frameworks based might be able to mitigate that and say, okay, for our current major version, we could just say we we've pony fill things or set certain things up. Is that still the case?

Alexander Lichter:

Do you have any insights on that?

Daniel Roe:

If that's the case, so it will we'll see how it ends up happening for Nitro three. If that's the case, we would adopt Nitro three sooner with any polyfills or polyfills that we we need if that's available. What Pooya and I are talking about maybe having an API compatibility layer for Nuxt version five and Nitro version three going forwards, meaning that future Nitro major upgrades don't necessarily require a Nuxt major upgrade. That would be quite a nice thing. Nice.

Daniel Roe:

Yeah. But regardless, I think it's a it's as much as and this has been true, like, if you think about it for Vite. Because Nuxt has been in one version of Nuxt version three. We're now up to Vite version six. And how many of those happened?

Daniel Roe:

Was it already up to Vite version three when Nuxt three was released? Or was it still two? But regardless, there's been at least three major versions that we've put out under minus of Nuxt, which is a like a testament to Vite being able to build these features and majors as well, while letting the frameworks that wrap them have little to note breaking changes to their users. It is also true, I think, maybe that Vite has a slightly different approach to breaking changes.

Daniel Roe:

So for example, Nuxt makes no - this is alluding to something you said earlier.

Daniel Roe:

So from my point of view, Nuxt is making no promises about node version.

Daniel Roe:

So we maintain the current LTS versions. We do not support end of life node versions. Even if Nuxt doesn't have a major version update, as soon as a node version becomes end of life, code may be pushed to Nuxt that doesn't support that end of life node version.

Alexander Lichter:

That's why I mentioned it like depending on how you see the perspective. I also know that for Vite, for example, Veed seven is also coming out very, very soon. And there's also the point of like, okay, you can drop node 18 now finally. But I agree that it always depends a bit while semantic versioning is in fact very clear. It can be taken out a very literal or a bit more deliberate depending on also what users expect and what the benefits are.

Daniel Roe:

I think the key thing for me, I mean, the idea of breaking changes, it's about documentation. The question isn't, does your project still work by only updating the Nuxt version or the version of the dependency? It's does it still do what it was documented to do? Because I think there are a lot of situations where So for example, if a package specifies a peer dependency and they bump that peer dependency, so saying we need a newer version. Is that a breaking change?

Daniel Roe:

Personally, I think not. I think bumping a peer dependency to a different major version will mean if you install it with the wrong one, you get an error or a warning. That's the point of peer dependency requirements. It's not a breaking change unless that it's documented that it supports that older version. So I think there are interesting questions here.

Daniel Roe:

And I know there'll be certainly people who take a different point of view from me.

Alexander Lichter:

I think the most important part is to be clear with that. I think with Nuxt, I think in documentation this is pretty clearly written. So that's always good to know for everybody who didn't know it out there yet. Now you're aware. And that means if you're still on Node 18, you better upgrade soon.

Daniel Roe:

I think Node actually released, controversially, released security advisories for all versions of Node. Basically saying there are no specific issues that we are aware of, but you need to know if you're continuing to use an end of life node version, you are putting yourself at risk. And that is, I think there were people who said, well, is an abuse of the security advisory system. But I think one thing it did send was a clear message that you should not be using end of life node versions. It's such an essential thing in terms of fundamental layer, running your code, controlling a lot of things on your computer that you just should not.

Daniel Roe:

You should have a regular release flow update as soon as a new LTS. Maybe not the latest version, but definitely as soon as anything is going out of into end of life, to be updating us.

Michael Thiessen:

For the next version of Nitro, what are the main breaking changes, new things for that? And for the people who maybe don't fully know what Nitro is and how it fits in with Nuxt, can you give like a brief sentence or two about how that works?

Daniel Roe:

So in Nuxt two, we had Connect. We used Connectors as a sort of node middleware type API with request and response objects coming in very powerful framework, similar to express, but a little bit more lightweight. And in Nuxt three, but basically in Nuxt two, when you built your Nuxt server, you still needed Nuxt around to run it. And so even your Nuxt config was still processed in production and Nuxt modules were loaded. And we did some things to optimize that.

Daniel Roe:

We had build modules, which meant that you could maybe drop some of those build dependencies like in production. But still, was possible. People were installing webpack and SASS and things like that in production. Not if you really optimized it. If you did, you might be loading stuff, but it was still in the order of, you know, 50 meg.

Daniel Roe:

So there you there was still huge quantities of code and dependencies, a lot more than you needed. And it was also optimized really only for running on node, on a long running node server. So when it came to Nuxt three and rethinking what we needed for Nuxt we re envisioned that server might look like and split it out into something we called Nuxt Sigma at first, and then it became Nuxt, like at Nuxt slash Nitro. And then pull that out of the Nuxt namespace totally and said, can be a thing on its own that supports deploying anywhere, serverless, Lambda, node-server, node-cluster, Deno, Cloudflare, anywhere. And not all of these platforms were even available when we started working on it.

Daniel Roe:

I think Cloudflare was the most known one that wasn't a classic node environment. But even so, running a node server is very different from running an AWS Lambda function or running on Vercel or Netlify. And as we went on, more and more options became available. And until today, there are so many possible options that there's even WinterTC, which exists to which looks at these different run times and even has a standardized way of talking about them, naming them. So that whole process meant that we have this separate server layer.

Daniel Roe:

It's basically the thing that ends up underpinning all of Nuxt. So the thing that ends up creating that server rendered HTML that we love so much. It's not involved in anything that happens in the browser other than serving the files that the browser needs and serving the HTML that leads to the browser making that initial request. But it's involved in almost everything else that happens on that server from API calls to caching, to the static assets. And it's an entire separate build that happens after the nuts part of your apps.

Daniel Roe:

If you're using Vite, for example, which you you are unless you opt out, you'll see that there's that Vite client build. That's the stuff that goes to the browser. Then there's like Vite server builds, which is basically just the equivalent of that browser layer, but for the server. It just renders the bit of HTML in that underscore underscore Nuxt div in your HTML. And then everything else that wraps that, well, that's a separate handler in Nitro, which ends up handling that piece of it.

Daniel Roe:

And so the Nitro build then happens. It takes in as an input, the Vite server build, as well as any other pieces for your server. And then it wraps all of that up and puts in a nice little package to deploy wherever you want. So whatever deployment platform you might be using.

Alexander Lichter:

I think that's a very good summary in terms of what Nitro is doing. One little addition is, of course, as mentioned before, that you can use those standalone as like another HTTP framework to build your APIs in or whatever you want. And we talked a bit about it in, well, more than 50 episodes ago, episode three of the podcast. So I I think that was that was a really nice summary, Daniel.

Alexander Lichter:

Thank you so much for that

Daniel Roe:

50 episodes ago. That is incredible!

Alexander Lichter:

More than 50.

Daniel Roe:

That's amazing.

Alexander Lichter:

Yeah. It's been a while doing this for more than a year by now.

Daniel Roe:

Happy days.

Michael Thiessen:

I'd like to also point out that Nitro is used in other Nuxt like meta frameworks for things beyond Vue. And I'm blanking on what the names are.

Alexander Lichter:

Analog, TanStack Start, SolidStart, Yeah.

Daniel Roe:

I would love to see more frameworks in that list, honestly, because the fact is that we're all tackling very similar problems in terms of adapters and different providers. And yeah, it feels like a shame to split those kinds of efforts. And I think that is happening actually. So it's a very, I think, very optimistic time to be looking, be building stuff with Nitro or H3 or any of the other underlying libraries. So, I mean, you asked about breaking changes, Michael, and I can't talk about all of them.

Daniel Roe:

A lot of them are coming from some of the underlying layers in Nitro because we've been aligning things with web APIs. So initially, when Nitro was first released, there was no consensus on what those things looked like. So what we had been coming from was node request and response objects. And controversially, Nitro got rid of that and basically said, we have a new event, an object, and still access the node request and response things. They're sort of buried under a couple of layers.

Daniel Roe:

And actually, gradually we made that harder and harder to do and gave people utilities. So instead of accessing request. Headers, you now use get request headers, like a little composable so on. Meanwhile, Cloudflare at the time had a request response, like a fetch request, fetch response based on the fetch API as their pattern. And that seems to be actually what a lot of the ecosystem has gravitated to.

Daniel Roe:

So stuff like hono was using it, Deno has a very similar kind of thing. And actually, well, it's a nice pattern. So we're thinking of moving H3 and Nitro to using that as the foundation of what event handlers look like. And that is can be done in a backwards compatible way, but it is probably one of the biggest changes that people will see and the biggest refactors that people will start making to their code base and to their those API endpoints.

Alexander Lichter:

On that note, a question regarding the format. Is this also what you mentioned regarding WinterCG or now WinterTC in terms of the common foundation that can speak with all the runtimes?

Daniel Roe:

So it is designed that way exactly. So there's a new if you haven't come across srvx, it's a new and interestingly named universal server API, which uses this new request response format, which you can very easily deploy to any of those runtimes. And it actually uses sub pass exports in its package JSON to ensure that the actual code that you're running is natively optimized for each runtime. So don't have lots of polyfills. This was something we did with Nitro originally.

Daniel Roe:

We basically created something that looked like a node request that any end response, but that would run-in any environment. So we're getting rid of that. So now we don't need to create that to pretend to be node. We can just default to this new native approach of having this request and response. So it's gonna make your code faster and smaller, which will be really nice because we're opting into this native approach while still providing that if you are running in fact on node.

Daniel Roe:

So it's pretty I'm I'm very excited. And I shouldn't probably talk about it, but the benchmarks are very nice too.

Alexander Lichter:

That doesn't hurt to mention. Even though benchmarks are always flawed. Yeah. But people people love them. People love numbers.

Alexander Lichter:

People love, oh, performance. And it's also good to mention because you don't want to make things slower necessarily.

Daniel Roe:

Even if you just look at it as benchmarking, not even not they look good across different equivalent servers and runtimes. But I mean, even if you just look at it from a point of view of our own performance, it's really nice to see new major versions coming out that significantly improved performance as over the previous one. That's the right direction to be going in.

Alexander Lichter:

I love the take off just comparing to yourself, first of all, because that's the benchmark people measure you as well. And then other frameworks, but still comparing yourself is important.

Daniel Roe:

Yeah. No, it's very helpful. And I think that's also the point of a lot of other things. So for example, a Lighthouse score isn't that helpful in comparing one website against another website. It's very, very helpful though in comparing your own website over iterations as you seek to make it better and prove it.

Alexander Lichter:

That checks out.

Daniel Roe:

A lot of methods like that, I guess.

Michael Thiessen:

Mhmm.

Alexander Lichter:

I think another question that came to to a few people in mind who maybe have read the announcement blog post that is probably out already when did episode airs is maybe it's also answered there. We Don't know yet. Why now? Like, why now? Why now?

Alexander Lichter:

Yes. Because of course we talked about it in the past. We could have pulled the plug earlier said, okay, let's release it without Nitro. But was it a sweet spot at the moment? It's like, okay, we have enough changes to justify a major version or what led to that point?

Daniel Roe:

So it's not that we're at a sweet spot. If I knew a year ago what I know now, I would have released Nest four then. It's not that we finally gotten to a point where we're ready to do it. It's more that I feel that this will be the best experience for users upgrading. Basically codify what exists.

Daniel Roe:

And I think it's always so tempting to say, well, we could wait just another week. But does that other week become another month, become two more months? And then in two more months, I'm saying, well, if only I had known back then what I know now. The thing is this is going to be a good experience regardless. So if Nitro comes out in one week's time, no problem.

Daniel Roe:

We're not delaying our support for Nitro at all. But what we do have is an intermediate major that gives people some confidence that what they've already been using isn't going to just suddenly break because some additional major change is going to be pushed to the edge of our commits. So this is about looking after people who are already there. And I think that's worth doing regardless. And going forward, we're not going to be in this position again, because again, we're thinking about API compatibility with Nitro.

Daniel Roe:

And just as we do with Vite, we don't pin or delay Nuxt releases just based on another tool that we use. We have other other options in in terms of a framework writing code that is backward compatible that handles different scenarios, and we can use that in in the future.

Michael Thiessen:

It also somewhat reduces risk and like the effort to upgrade. Think if it's split over two major changes, because you can do the upgrade to four and then, okay, that works. As you know, a few things that you maybe had to fix maybe. And then a little bit later, then five comes out and then you can do that upgrade and it separates it out and you don't have to necessarily tackle them all at once to fully get onto the next major.

Daniel Roe:

Exactly. And honestly, people could, if they wanted, choose to wait and just go straight to five. But I do think that that intermediate step is just gonna even make the migration more straightforward. Even if you're on three and version five is out, I would still do it first four, then five because it just makes it hopefully quite logically clear which bits of your code you're changing. So you're upgrading three to four, great.

Daniel Roe:

Don't touch the server directory. You don't need that.

Alexander Lichter:

Except moving it out or like moving everything else, the app folder if you wanna do the server structure.

Daniel Roe:

That's right. Yeah.

Alexander Lichter:

Maybe don't touch the server directory if you don't move that and all the rest. It's not wrong.

Daniel Roe:

Yeah.

Alexander Lichter:

It's also given the migration guides, it will help a lot. It's like, hey, here's a clear cut from three to four.

Alexander Lichter:

And then you go through that and then you go through one to five.

Alexander Lichter:

I was wondering because we talked about LTS in terms of Node for a little bit. Now how are the plans for long term or at least term support for the NUXT major version? So what will happen when Nuxt four is out? How will Nuxt three be treated?

Alexander Lichter:

And then subsequently five and four.

Daniel Roe:

The plan is for Nuxt three to get a minimum of six months of support. That was what we've been saying for a while. And the plan will be, even though we're expecting Nuxt four to be very quickly eclipsed by Nuxt five, so we're not expecting for it to be the active release for very long, but we'll do the same.

Daniel Roe:

So we'll give that again a minimum of six months of support, even though Nuxt six. oh Nuxt six, Good lord.

Alexander Lichter:

Another announcement, Daniel.

Michael Thiessen:

Woah.

Daniel Roe:

Just it. We're firing through it. Our new release schedule is one a month, right? Oh, yeah. Not the plan.

Daniel Roe:

So even though next five will be the focus, we'll still be back putting features and bug fixes to three and four. So it's going to be it's gonna be some work on us as the team. But I think it will make people's lives easier and better in the upgrade phase. It's worth it.

Alexander Lichter:

Sort of, let's say, worst case as a maintainer, that means you port things back to four and three at the same time. Yeah. And how about bridge?

Daniel Roe:

I mean, honestly, I've been doing this for a year, maintaining both the main branch four.x and three.x. Like we've been cherry everything is cherry picked back to three.x.

Daniel Roe:

That's not the active branch.

Alexander Lichter:

True.

Daniel Roe:

Yeah, doing it one more, think it should be doable.

Daniel Roe:

Bridge, Alex, Bridge. Well, so I think the scenario for Bridge is that it's a tool to help people migrate from Nuxt two to Nuxt three.

Daniel Roe:

So Bridge itself is a Nuxt two module. So we are doing our best to look at it. It's not actively being looked after from my point of view, but we thankfully have members of the team like Ryota who are doing amazing work in keeping it going, which is just fantastic. Which probably does deserve a release because there are some nice bug fixes that have have been shipped that that need to be be released. But, you know, that's not being actively maintained other than by the community.

Daniel Roe:

So and and Ryota is part of the ecosystem team. So

Alexander Lichter:

And that would mean next to to next bridge, to next three and then four five.

Daniel Roe:

So, I mean, if you're migrating from bridge, I'd probably go straight to version four, honestly, or straight to to five.

Alexander Lichter:

Or whatever we have when you listen to the episode in a couple years.

Daniel Roe:

But, like, the differences between the whole point, I think, the difference between two to three is a huge difference. The difference between three and four and five are not that significant. So there should be very little different that you need to do. So yeah, you can migrate to version three and change it to version four. But I would just go for version four.

Daniel Roe:

It shouldn't make that much difference to the migration process other than a different directory structure.

Alexander Lichter:

Makes sense.

Daniel Roe:

You're not asking about the dates though.

Daniel Roe:

Or maybe you did, Michael. Maybe you're just thinking, don't know.

Michael Thiessen:

I did ask about the dates. But before we get to that, I have a question about if you ever consider just skipping four altogether and just sticking with prime numbers as the version release, the major numbers?

Daniel Roe:

I have now. And I think it would start off very promising. And if Nuxt intends to keep going as a framework for some time, it will rapidly become more difficult.

Alexander Lichter:

That's true. But actually, the the idea of skipping for people in the community have voiced that multiple times. Oh, yeah. You can align with the number of the year, 2025, get max five, and this might still happen now.

Daniel Roe:

You know?

Alexander Lichter:

So maybe that was just Daniel's approach to get back on track in terms of aligning that. But yeah. I mean, would be the benefit in skipping four straight away like PHP did with, well, we all know which version?

Daniel Roe:

My favorite version hack that we did was 3.14.159. That was that was that was basically, you just added additional digits of pi to the That was really good. Version number rather than increment in a normal fashion. That was great. I loved it.

Alexander Lichter:

Same. That will always stay in our heart and probably end up as a view trivia question in some quiz.

Michael Thiessen:

Exactly. Yes. Probably.

Daniel Roe:

I will tell you, though, one thing I would like to do, maybe I should do it for version four, is have code names for our minor releases.

Alexander Lichter:

Like Vue has as well.

Daniel Roe:

Yeah. Like Vue has because I feel like this is a missed opportunity. So you you get thinking.

Alexander Lichter:

But what would you name them off? Like, what would put your name after, not off?

Daniel Roe:

Well, I'm not an anime watcher, so I I don't really play video games. So if if you're looking to me, like, I I I'd I'd be having to do stuff like, I don't know,

Alexander Lichter:

Bouldering Gyms

Daniel Roe:

Books of Anthony Trollope, maybe? That would be Barchester Towers. We could do something like You're not amused. Well, we could have a discussion about this.

Alexander Lichter:

No, no, Daniel. We do a poll. There is no discussion. We do a poll. We let the

Daniel Roe:

The community can decide, and Boaty McBoatface will be the next minor.

Alexander Lichter:

Yes. Like, most liked comment on all platforms. We end up with we end up with horrible names, but it's fun.

Michael Thiessen:

I think it should be something like obscure so people don't don't immediately get the reference. And then they have to like look it up or something. I think that would be

Alexander Lichter:

How about favorite karaoke songs, Daniel? What do you think about that?

Daniel Roe:

Favorite karaoke song. So the first one would be Row Row Row Your Boat because that is going to be the next song that you and I sing at karaoke. Right?

Alexander Lichter:

Definitely. So then we have the codename.

Michael Thiessen:

And then you can have when you install it, it plays that minor version's theme song.

Alexander Lichter:

Oh my god. That's A little animation in the in the terminal, like, a little boat that's oh my god.

Daniel Roe:

This would be so bad. This would be so but also genius at the same time. True. We would have to play it in a very, like, video arcade way.

Alexander Lichter:

Yes. Like a low fi, like an eight bit version or something. Yes. Yes. Yes.

Alexander Lichter:

Yes.

Daniel Roe:

Like, it doesn't matter. We even if we have the capability of playing it high fi, it has to be as low fi as possible.

Alexander Lichter:

100%. If you could do it on the landing page or the blog post or something, that you'll link to the platform.

Daniel Roe:

I think it'd be fun. You could actually while the dev server the dev server would be ready, but before you're allowed to develop your site, you have to do a little platform game. You're like, jump. Then Like the Chrome

Alexander Lichter:

Dino. Yeah.

Daniel Roe:

Exactly. Have to go. That would be fun.

Michael Thiessen:

These are all fantastic ideas.

Daniel Roe:

Yeah. We should win them all.

Alexander Lichter:

Coming and jumping over mountains and collecting green triangles. Oh,

Daniel Roe:

You should do this, Alex.

Alexander Lichter:

What did we get us into here? What did we get us into here?

Daniel Roe:

I think we were talking about the the fact that we should have released names. But really the question is what are the release dates? I should be asking that question.

Alexander Lichter:

Wanted to ask at the very end. So everybody is still intentioned the whole episode over And they don't just skip to the chapter mark that it says, when release date? Mark. Ah, I see. Yeah.

Alexander Lichter:

Daniel, drop us drop us the dates. Tell us now. It's time.

Daniel Roe:

So alpha of Nuxt four is already released as of Monday. Oh.

Alexander Lichter:

Isn't it already released as in future a compatibility version four?

Daniel Roe:

It's not released as of the moment I say this. It's released as of the moment you hear this because it will be out on Monday with the blog post, alpha of Nuxt four. That's my plan anyway. And then the aim is to have Nuxt four stable release out by the June. So quite an aggressive release plan.

Michael Thiessen:

Wow.

Alexander Lichter:

That's tough. Okay. I'll block the June

Daniel Roe:

How does that sound, Alex? Because I'm aware that this is the first time we have actually talked about it.

Alexander Lichter:

Yes. Well, I mean

Daniel Roe:

You onboard? Should we delay?

Alexander Lichter:

Let's do it. Let's do it.

Daniel Roe:

Let's do it. That's fine.

Alexander Lichter:

I've blocked the rest of the month. It's fine. I only have one conference that we attend together. And then we're good? Perfect.

Alexander Lichter:

Crunch time.

Daniel Roe:

Yeah?

Michael Thiessen:

I'd like to bring your attention to this

Alexander Lichter:

problem.

Michael Thiessen:

To wait. I'm trying to send a link here too to a post that I sent a while ago where I did a ChatGPT generated comic. Oh, yes. The the date in that is

Daniel Roe:

very interesting. Eerily close.

Michael Thiessen:

I did not put in my prompt anything about the release date or any details about that, just the actual like panels. And then it just decided to fill that in. And for those listening, it's a, it's a comic that I made with me and Daniel Roe where I say, I know when the, the next four launch date is, and then it shows my phone that that Daniel Roe sent me a text saying June 13.

Alexander Lichter:

It is Daniel

Michael Thiessen:

Not too far off.

Alexander Lichter:

Should we just make it June 13 then for the memes?

Daniel Roe:

I've just noticed that in the group chat, it says, Darie Dari. Dariel? It's Dari. But, like, exclamation mark. An hour.

Alexander Lichter:

Darin. god.

Michael Thiessen:

Also, if you look at my ear in the first panel, I've got, like, an extra earlobe.

Alexander Lichter:

Or an earring?

Daniel Roe:

It's an earlobe slash earring. Yeah. It's disturbingly similar to both.

Alexander Lichter:

But nevertheless, we have still the chance. The podcast is not out yet. We can cut no kidding. But the podcast is not out. But should we make it in June 13, or do you think we need a month of aggressive aggressive timing?

Daniel Roe:

We'll see. I'm not averse to releasing it a little bit earlier than the June. We also have another person on Bluesky who said that if we released it on the June 23, he would quit his current job and go back, which he's building Next.js and he will go back to building Nuxt. So that is also a reason why we might bring the release date up soon.

Daniel Roe:

But if anyone gives me a better offer, you know, any bids, any, you know who knows? We could we could discuss dates. But

Michael Thiessen:

then bribes.

Alexander Lichter:

June 23rd sounds more even more appealing. Yeah. The the bids are opened. Write in a comment what you would offer to Daniel Rowe and the next team to release to release it earlier or at all.

Alexander Lichter:

I mean, now we know it will happen. And we can see the light at the end of the the Nuxt four road slash tunnel, so to say. Daniel, is there anything else that we didn't cover so far that you wanna share with the the DejaVue listeners and the wider community in the Vue ecosystem or maybe even beyond that regarding Nuxt four or five or six.

Daniel Roe:

Or six, which we discussed today, but I wasn't planning on talking about nothing more, think. Only that this is only really possible because so many people have been testing it. I really appreciate that. So thank you.

Alexander Lichter:

Perfect. Yeah. Thanks to everybody using the compatibility version. Reporting bugs with minimal reproduction, always appreciate it. Raising issues, contributing as well in all different ways.

Alexander Lichter:

Yeah. And then, last but not least, where can people where can people follow you? Hope you'll find you.

Daniel Roe:

I have a website at roe.dev where I can have links to most other things. But I'm pretty much on every social media platform except for Twitter. So give me a DM if want. If there's anything I can do to help, I'm always happy to be contacted.

Alexander Lichter:

Perfect. Then check out the announcement blog post, which is out when you listen to this episode and also linked as well as all the other links we've provided. Continue listening if it's not the most recent DejaVue episode and otherwise well, we also shared a few about Nitro, the Road to Nuxt four. Hot and spicy predictions for 2025, and some of them became true already. So check them out definitely.

Alexander Lichter:

And thanks everybody for listening and watching, folks. See you in the next one.