Nuxt Migration from 2 to 3

[danielroe]

One of our priorities for 2023 is to assist people to migrate projects from Nuxt 2 to Nuxt 3. You can read more about our vision here, but the key section is here:

On December 31st, 2023, Vue 2 will reach End of Life (EOL), and with it Nuxt 2. Both Vue and Nuxt will continue being available and working for many people, but at the same time, many companies and users will want to transition to Nuxt 3 (and we'd encourage this!).

Part of our focus this year therefore will be supporting everyone who wants to migrate their apps to Nuxt 3. We'll also be working to backport key bug fixes and security fixes to Nuxt 2.

In addition, there is Nuxt Bridge. It was built as a module to bring features and bug fixes from Nuxt 3 back to Nuxt 2, although it has not yet been released in a stable version. We plan to stabilise and release it in the next month or so, but our main focus over the course of the year will be on helping people transition to Nuxt 3.

In order to do this, we have a number of tasks before us:

• Improve migration guide from Nuxt 2 -> Nuxt 3 (see Migration guide for Nuxt 3 #15981)
• Add migration guide from Nuxt Bridge -> Nuxt 3
• Gather feedback from Nuxt 2 users about migration blockers
• Ensure that the most used modules in Nuxt 2 are updated or have a straightforward migration path.
• Release Nuxt Bridge and switch to semantic versioning for releases.

We would really value your comments and help in this process, particularly in improving the documentation and highlighting key modules that we need in the Nuxt community.

[Suniron]

I'm stuck with nuxt bridge since I have more than 2000+ implementations of Vuetify (belong to nerly 220 components)..

I hope there is a solution in the future to make the migration easy 🙏

[bmulholland]

We migrated to Nuxt Bridge some time ago and have been stuck there. I've tried twice to figure out an upgrade to Nuxt 3, even without the modules below, because maybe some things will work and we don't actually have to upgrade or change all together (e.g. because we don't use SSR). The lack of documentation on Bridge -> 3, which you noted, has prevented me from doing that. I'd be able to comment in more detail on other difficulties once I've made an upgrade attempt.

Documentation

The upgrade is imposing: the work is coupled with all of Vue 3, Vue Apollo 4, Apollo Client 3, and Webpack 5 -- plus all their dependencies. Also, as many modules no longer support Nuxt 3, we have to change a lot of other pieces at the same time, see below. I'm not sure that Nuxt can help with any of this, but if there's ways to smooth the upgrade or make the chunks of work smaller, it would be very helpful.

AFAICT, Nuxt 3 also comes with Vuex -> Pinia, which we believe we can do before the huge upgrade to reduce risk. Documentation on upgrading to Vuex->Pinia, and especially how to do that on Nuxt Bridge, would help us with that; Pinia is a little sparse on the Nuxt-specific help. Alternatively, info on how to upgrade to Nuxt 3 while keeping Vuex would also reduce risk.

Modules

There are several modules that are not ready for Nuxt 3, or will not be supported:

• nuxt/auth. Enough said :). We plan to just move off of nuxt-specific auth modules and use a more common module for our oauth instead.
• dayjs doesn't seem to have a Nuxt 3 version coming anytime soon. There's a replacement module at https://github.com/fumeapp/dayjs
• toast -- which is "legacy" but also has no suggested replacement. We can probably just switch off of nuxt/toast to the underlying vue module, then replace that?
• storybook -- a complete blocker to upgrading, I think. We can't run storybook otherwise, and there's no replacement. I know Daniel is working on something that might help storybook, but only for vite, and I want to keep vite out of the list of things I need to change at once.
• svg-sprite UPDATE -- added Nuxt 3 support
• Nuxt Sentry is still working on Nuxt 3 support. I've been monitoring their progress for months and it's clear they've put in a ton of effort, including struggling with Nuxt's module support (e.g. they wanted to support v2, bridge, and v3 in the same code/release, including tests, which prove doubly impossible).

Ideally, we could upgrade these directly to their Nuxt 3 version, or could swap to the replacement module while on Nuxt Bridge. Anything to be more incremental in the upgrade. Guidance in the docs, even a quick suggestion, would be really helpful here (e.g. "Nuxt team recommends these Nuxt 3 replacements for Nuxt 2 modules: svg-sprite -> nuxt-svgo, ..." or whatever).

[bmulholland]

Update: there's a Nuxt 3 dayjs module at https://github.com/fumeapp/dayjs

[cas-technology]

Alternatively to @Xowap 's solution for Sentry, there is also a tiny plugin file (for use in the plugins directory without any other config) available. This wasn't made by me but I can't find the original source, sorry! see this gist

[DenFin]

@bmulholland what did you choose instead of a nuxt specific auth module? I guess you did not go for sidebase/nuxt-auth because it isn't stable yet?

[bmulholland]

We haven’t done this work yet, we’re still blocked by Storybook. We’ll probably move to Auth0 or similar, maybe together with a raw oauth JS library.

[DenFin]

We are currently using @storybook-vue/nuxt in one of our smaller Nuxt 3 projects. It is working okayish. We can display all of our atomic components which are basically just dumb components with props/slots. Displaying a component that uses NuxtLink unfortunately doesn't work. For our smaller project this will work for some time

[reinoldus]

I tried to upgrade from nuxt2.15.x + composition-api to nuxt2.16 + bridge and got stuck there already, I described the issues I had here: nuxt/bridge#707 Summary: What I'd need here to make any progress is a path from nuxt/composition-api to bridge without any other feature. That wasn't clear to me how that would work.

In order to use any of the other features of nuxt/bridge, I have the following module issues that do not support bridge as far as I can tell, also not sure if the module has to support bridge or if the old module setup would still work:

• nuxt/auth - if @sidebase/nuxt-auth would support bridge, I could make the switch
• @nuxtjs/sentry
• @nuxtjs/redirect-module - This one I could probably ditch and do it with nitro Nuxt 3 support? nuxt-community/redirect-module#120
• @nuxt/content - Stuck on v1 can get rid of it
• @nuxtjs/apollo
• @nuxtjs/style-resources - nuxt3: resolver.resolveModule is not a function nuxt-modules/style-resources#190 (comment) Probably fixable through this
• bootstrap-vue (working on getting rid of it)

Once I manage to use bridge instead of @nuxt/composition-api then I could be more helpful, but I am stuck there already.

[anjali89r]

We are in the process of upgrading, but some of the existing nuxt 2 modules are not supporting nuxt 3 and it requires us to spend a good amount of time implementing a solution for it. This is really slowing down the migration. A few modules which are being used are,

1. nuxt-amp module
2. nuxt-sitemap
3. nuxt-pwa

[dhaladitya108]

@anjali89r did you figure out something?

[nestle49]

We've been trying to migrate a large project from @nuxt3 beta to release, but problems started with @nuxt/bridge. By the release of the third version, it became clear that this is obviously impossible and is unlikely to become possible for large-scale projects in the future.

Therefore, we decided to migrate to vite, piece by piece building the project again. And I must say that it turned out to be much easier, the whole migration took about two months (instead of vite it was possible to migrate to nuxt3)

[Austio]

Similar here, we have a couple a large nuxt app and the process for upgrading really causes me to question the viability of using nuxt for larger projects. I understand the need to iterate from the team but the disregard for real paved path for an upgrade along with core breaking changes makes me question whether it makes sense to use nuxt in an enterprise like context. It may be ok for people that like to take time away from the business in order to rewrite their apps every so often or for smaller projects.

Very interested in the path you took @nestle49 to get away from nuxt and how you handled bridges for things like middleware/plugins. We used to maintain our own SSR before moving to nuxt and it was significantly less burden on the team for changes.

[bmulholland]

I want to echo what @Austio and @nestle49 say here. It seems pretty clear that the Nuxt community is heavily oriented toward spinning up new projects on the latest version which are not really maintained after that. Ongoing maintenance of non-trivial projects is clearly less than an afterthought. I'd call lack of clear migration instructions 6 months after launch "neglect;" this Discussion topic was started a month ago and has resulted in zero visible response or changes.

I used to help manage the also-neglected Nuxt Auth module, until the decision was made -- without me -- to completely re-write it. I raised concern about the realistic timing of that when it was announced, and I was right: it's been six months since the release date of 2022 was removed from the roadmap. My concerns from the beginning have been that auth is a deep project with a ton of edge cases, and it's hard to test (manually or automatically). Even if a re-write does come out, it will take years of hardening to even reach the point that the current nuxt/auth module is at, which frankly isn't very good. It's just not going to be viable work, and that's why I'm going to switch off nuxt/auth.

The Nuxt 3 upgrade docs still saying they're a WIP. Meanwhile, Nuxt 3.3 has been released, and their roadmap says "major releases every year." At this rate, Nuxt 4 will be out before an upgrade path for anything using the auth module is available, or instructions on how to upgrade from Nuxt 2 to 3 are complete.

I've done what I can to raise blockers with people on the Nuxt team. IIRC, Daniel created this Discussion after I chimed in on Discord. I've made active suggestions on things that can help, and I've tried to raise high-leverage, root-cause blockers (e.g. items that are blocking the storybook module, which are blocking me).

Nothing I've raised has resulting in shipped product or documentation. I'd love to be coming across as collaborative and helpful. From the lack of response, I'm left feeling that I'm instead just being annoying. It's hard to imagine that helping existing projects more broadly is seen as anything else. I regret using Nuxt for my company's product and am seriously considering a migration off Nuxt: even if we work through the upgrade, what about the ones after that?

[danielroe]

I appreciate your comments, and wanted to add a note.

Helping people migrate from Nuxt 2 -> Nuxt 3 is something we really care about. Indeed, it is one of our main priorities for this year. Honestly, I think we didn't get the rebuild of Nuxt 3 right - either the timeframe, the level of breaking changes or the communication along the way. But that's something we're trying to fix now.

Going forward, we'll be there for the future. I understand you're wary. But I hope we can win you over during the course of this year. And Nuxt 4, when it comes, won't be like the upgrade to Nuxt 3. We are planning in advance for that migration, which should entail minimal changes in user projects and will ideally be automated with our new CLI.

But that isn't something we can do alone. We're relatively small team (though, I hope, responsive). PRs, feedback, and amazing community work on modules (see elsewhere in this discussion) is needed. Pop in the #contributing channel on Discord or let me know if you'd like to pick anything to work on. We'd all be very happy to help where we can.

---

Side note: I'm sure @pi0 can comment with more details about auth, but the decision we've taken from a framework perspective is not to rewrite the auth module as it is now, but instead provide a framework that other modules (like https://github.com/sidebase/nuxt-auth) can make use of. That's why it's not just a matter of updating the module to work in Nuxt 3. And we're not aiming to reinvent what others are doing. I am sure he will be working closely with the team there to make sure what we build is fit for purpose.

[bmulholland]

Thanks for your response, Daniel! I truly appreciate the hard work you and your team are putting into this — it's clear you're managing a complex project. I wonder if greater community engagement and enablement could amplify the impact of the limited resources you have. I'm more than happy to discuss this further if you find it helpful. Looking forward to seeing how these priorities shape the migration documentation in the near future. :)

[nestle49]

@Austio @bmulholland @danielroe

A little late answer, but I'll share my observations

Middleware were implemented through router meta fields, plugins remained code modules connected at the entry point (we have 2 entry point for server and client, first plugin is equvalent nuxtServerInit)

We started migrating a year and a half ago, and although we successfully migrated to @nuxt/composition-api, nuxt/bridge was in a sorry state, we waited several months, but as a result, rewriting everything again turned out to be easier (although we didn’t think so) because the time for the refactor was already much less than the waiting time (despite @danielroe help)

We migrated to a self-written solution with vite-ssr-plugin, because at that moment we expected similar problems with migrations in the future and wanted to avoid delays, and not sit without a new existing version of vue for two years again, although we still watch nuxt with interest

We have gained a certain flexibility in implementation capabilities, but at the same time complexity, we have to be distracted by things that nuxt previously provided

Now, after a year of supporting a self-written solution, my opinion has changed; I don’t see any problem in migrating from nuxt2 to nuxt3, even completely ignoring the bridge. Therefore, I was surprised to learn that there is progress in this direction and even a little disappointed (by the fact that the team is spending time on this).

Nuxt still lacks some flexibility (or perhaps documentation), for example, I don’t understand how to organize routing if all url addresses come from the api?) However, my personal opinion is that the migration is worth it, besides, if you migrate bypassing the bridge, you can migrate only the business logic of the application, getting rid of the legacy that has accumulated over the years

[Xowap]

As I've got a few hundred of thousands LoC of Nuxt 2 code to update, I'm currently having my team work at compatibility layers for things that we use:

• Axios — We don't want to be re-writing all API calls
• Proxy — Couldn't make it a drop-in replacement for the proxy module, but close enough so that we could adapt it for what we need (we got kinda complex rules to play nice with Wagtail, the CMS we use)
• Sentry — Integration with Sentry

Those are the main pain points that we've fixed as we expect that given the way we use Nuxt it's going to be the most impactful ones, and many more are probably to come. We'll be happy to collaborate on this.

[danielroe]

I'm really delighted to hear that. Thanks for letting me know.

[DenFin]

@Xowap how did this work out for you? did you make any surprising observations?

[Laruxo]

We've just finished upgrading our app to Nuxt 3, and boy it was a journey (~2 months). We went directly from Nuxt 2 to 3 without the bridge, which was the right decision. Even today, it does not seem like there is an easy path to go from nuxt-bridge to v3.

The initial migration to make Nuxt 3 run was quite easy, and we managed to make the standard SSR app deployment work without big issues. However, there were a few pain points in finalizing everything:

• Storybook, we rely heavily on it and so we had to make a really ugly mock of useNuxtApp to make it work for us. nuxt-vitest and histoire was a great inspiration here, but it would be nice to see better support for Storybook.
• Testing still is not perfect and I think the worst part was the lack of documentation. From the docs it is not clear if we should use nuxi test (or what it does exactly), or vitest with nuxt-vitest. We went with the second, since the speed is way better and we don't need a full Nuxt app running for tests.

Of course, there were lots of issues related to Vue 3 update, but those will be different for each project anyway. One thing to note, that if possible it is better to keep components in options API to reduce the number of bugs related to migration to composition API.

All in all, I am really happy we did it, because the DX and performance is superior. However, if the supporting tools would work out of the box, I think we could have finished the migration in half the time.

P.s. we don't use any community modules, instead integrating Sentry/Tailwind/Apollo directly, so at least this part of the migration was easy.

[DenFin]

Thanks for sharing your experiences. Would you mind elaborating on why skipping Nuxt Bridge was the right way in your situation?

[Laruxo]

We only use two 3rd-party modules, so their compatibility was a non-issue. However, some of our modules were highly dependent on Nuxt 2 core functions, so we had to rewrite those modules for Nuxt 3 anyway. After that, it seemed straightforward to go directly to the newer version.
Most other issues were related to the Vue 3 upgrade and tooling (testing, Storybook), so we had to solve them anyway.

Finally, even today I don't see a straightforward path to go from Nuxt bridge to v3. I imagine that if we had shipped our app to production using Nuxt Bridge, we would still have it there even now. With direct migration, we had to spend more time, but now we immediately have all the benefits (performance boost, dev experience, SWR, etc). I think that Nuxt Bridge is a great solution for simple apps where it "just works". If migration to the Bridge requires a lot of effort, then it is not worth it.

[DenFin]

Thanks for your quick reply! Which modules did you use in the Nuxt 2 project?

[Laruxo]

Sentry and Tailwind (and previously required @nuxt/postcss8 and @nuxt/typescript-build). With Nuxt 3 we integrated them in another way without modules.

[rinux55]

We're in the process of migrating from Nuxt 2 to Nuxt 3. One of the things I've been working on most is upgrading our own Nuxt module. I think code wise things are pretty nice and straightforward, but once you get into testing territory things feel more bare bone. Unfortunately it feels a bit as testing was an afterthought. For someone who likes to practice a TDD approach as much as possible, testing with nuxt was not a nice experience.

Luckily things are getting better day by day thanks to the effort of @danielroe and others working on nuxt-vitest. That package is helping us out tremendously!

I have a list of my findings:

Testing a module

playwright

The solution provided in the documentation of testing the module with playwright was not working well for us. Our module is pretty big (it provides components, composables, plugins and installs other modules), and testing it with playwright and a fixture was very slow and sometimes even flaky.

Testing the output of the module with different configurations got very cumbersome and difficult to maintain very quickly, as each different configuration relied on having a different fixture.

Often we just needed to assert that a certain function was called during the build process, but this was impossible due to playwrights nature. In the end we had to abandon playwright, because it was not fit for our usecase at all.

nuxt-vitest

Luckily we found nuxt-vitest. I was able to load nuxt-vitest with a fixture in a similar way as with playwright. I don't think it's built to test modules per-say, but it does a good job at testing all runtime code. There are a few things which could use some polishing:

Mocking composables and other imports

With vue 2 it was super easy to supply mocked plugins to your components by providing $mocks.
Composables are great, but they are a bit harder to mock. Add nuxt's auto imports to the mix and it becomes really cumbersome. mockNuxtImport does a decent job, but as soon as I need to mock the provided import because I want to validate if something has been called, I must create a separate file which provides the mocked function, because mockNuxtImport is hoisted at the top of my file.

It would be super helpful if this becomes more fluent, perhaps something like:

const { useMyComposableMock } = mockNuxtImport('useMyComposable', () => vi.fn())

[...]

expect(useMyComposableMock).toHaveBeenCalled()

Validating head

It's difficult to test anything that uses the useHead composable, as head is not being rendered by happy-dom. I'd love to use @testing-library to just check what is rendered in head. I could mock the useHead composable, but again, right now this is a bit of a pain.

Missing documentation

It was difficult to find the right documentation. Especially on testing there was not a lot to find. Often I find sections with links linking back to eachother, none of which are providing an answer. Some sections in the documention just link to the source code. This was nice because it gave me a deeper understanding of what was happening, but this should really be more comprehensive.

Conclusion

All in all, I love Nuxt. It's clean, simple to use. But testing with it is not good enough yet. It would be an amazing developer experience if testing was just as easy as working with Nuxt. I think nuxt-vitest is on it's way and it's great to see how quickly issues are being picked up.

Thanks @danielroe and all the others for putting in all the effort!

[DenFin]

@rinux55 How did the migration work out for you? Would you mind sharing some of your experiences?

[rinux55]

Since I wrote. this post, a lot of work has been done on nuxt-vitest. It has now been merged into @nuxt/test-utils, and I've been testing extensively with it. Most of the issues I've had are now resolved, and writing unit tests for Nuxt is now pretty intuitive!

[daktas]

Hi guys,
on my Nuxt2 project I had a routing.js middleware file to serve content from api for exemple from my robots.txt

if (route.path === '/robots/') {
      const { data, status } = await $axios.get('/api/v1/content/robots/');
      if (status === 200) {
        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.write(data);
        res.end();
      } else {
        throw 'Error generating robots';
      }
    }

I try to do same on Nuxt3 migration but seems not work same any clue on how to serve data directly ?
I try to do from server but not work because I need to access store to pass some data in header.

[deleteme]

I have some feedback and suggestions after spending a considerable amount of time evaluating Nuxt Bridge and unsuccessfully trying to use it. Over the course of evaluating it, I filed my share of bugs in order to help the project out.

The central value proposition from Bridge currently is "Experience Nuxt 3 features on existing Nuxt 2 projects." I feel like this is missing the point. Bridge is a means to an end, in this case, upgrading an app to Nuxt 3, preferably without breaking it along the way.

Bridge features and functionality should be reorganized to enable Nuxt 2 apps to gradually and safely apply Nuxt 3 changes. In doing so, what would be a large risky process is broken down into smaller, safer change sets that can be shipped.

The current docs and feature flags are presented as a big pile of changes and settings, without clear direction on how to use them. Some of the feature flags rely on others. Some of the defaults are risky (nitro being enabled).

Here's a proposal of what I mean:

The first step could be adding nuxt bridge to package.json, maybe making other dependency edits, maybe minor tweaks to the nuxt config. All feature flags would be disabled. The result of this is so that people can have bridge installed and plugged in, but not doing much at all, and definitely not breaking anything.

Every subsequent step on the bridge should be obvious, incremental, safe, and shippable. The bridge should be stable and give confidence that the app is on solid ground.

Possible next steps, not in any particular order:

• update the runtime config, and ship it
• update the plugins format, and ship it
• update the middleware format, and ship it
• for each composition function
  • migrate away from @nuxtjs/composition-api, and ship it
  • This may seem like overkill, but in a large app, each of these can touch hundreds of Vue components.
• for each feature flag
  • enable it, make whatever necessary changes are needed, ship it

The steps should be organized from least risky to most risky. At the end of the bridge, maybe both nitro and vite would be enabled, and all of these changes were valuable because they would've otherwise been done all at once in a giant Nuxt 3 upgrade branch. Finally, the gap between the bridge and Nuxt should be clear, small, and documented. Maybe some tasks in the gap can be shifted into the bridge.

I hope that this can provide clarity and be an inspiration for the future management of the Nuxt bridge project.

[bmulholland]

Unfortunately I don’t think there has been any new work meaningful on Bridge in the last six months. I also haven’t seen much new work in helping us upgrade to Nuxt 3 in that time. Docs are still frozen where they were. Happy to be proven wrong if anyone knows?

[Aareksio]

We are in similar state, having reasonably large apps on nuxt 2 unable to easily upgrade. Business-wise we do not care for nuxt 3 features. User land code is also generally compatible with Vue 3. But we can not upgrade, despite the dread of Vue 2 EOL coming soon. Last time we tried bridge, we got a lot of cryptic errors that weren't very helpful, even after months of nuxt 3 dev experience.

Luckily nuxt 2 is still perfectly good to work with :)

[danielroe]

I would welcome any update to the docs with this suggested migration plan. I think these are reasonable proposals.

The plan is for us to stabilise Bridge and release as RC soon. I think adding additional test cases is an important piece of this.

[yoshrubin]

@danielroe I think the main question that still remains which is will there be a way for nuxt2 users to incrementally add the features from nuxt-bridge into an existing nuxt 2 app so the eventual upgrade to nuxt3 will go over smoothly

[bmulholland]

Just in terms of mapping it out, the timing now is either urgent or it won't be useful.

Specifically: Vue 2 EOL's @ EOY. December is always a write-off, and who wants to deploy a major infrastructure upgrade right before holidays? This leaves us with Sep-Nov, inclusive. As end-users (devs using Nuxt Bridge), we'd need at least a month to implement and ship whatever is delivered here. It sounds like there's nothing concrete planned, so take a month for planning, development, and delivery. At best, if a person or team dropped everything and worked on only this, and us users of Nuxt also dropped everything to ship it immediately, there's a month of flex time before it's not useful

That's pretty tight.

@danielroe What does "stabilise Bridge" mean? What's left before it's an RC? How does the timeline for that fit in with the above? Also, how does updating the docs to map out a path from Nuxt Bridge to Nuxt 3 fit into that?

[Lehoczky]

First of all, I want to say that we are very thankful for the hard work you guys are doing to make nuxt a great framework! There are exciting new features with every release, and it feels like you guys have an infinite amount of other cool ideas that haven't been implemented yet.

But I also feel like the handling of the migration has become a bit of lower priority goal in the last couple of months. A large chunk of the ecosystem still don't have a stable release for nuxt3 including nuxt-image, nuxt-i18n, nuxt-auth, nuxt-storybook. I would say all of these are important modules for enterprise applications. So important, that we can already see alternative solutions from other developers like:

• https://github.com/hirotaka/storybook-addon-nuxt and https://github.com/storybook-vue/storybook-nuxt for storybook
• https://github.com/sidebase/nuxt-auth and https://github.com/Hebilicious/authjs-nuxt for auth

Which is great in one hand, but also started fragmenting the ecosystem on the other.

I think the community would be very grateful to have these essential modules migrated to nuxt3 and also focusing a bit more on just bug fixes and performance improvements.

Server components, the new cli, new versions of nitro and h3 all sounds great, don't get me wrong! I think all of us are happy to see that you are looking forward to make this framework always better and better and possibly the best of all meta-frameworks. Some folks though are still struggling with the nuxt2 migration and I think they might need a little more help.

I also understand that the team might be very thinned out. Lot of features for a small team, and I urge everyone from the community to try to help out in every way they can: write a few more lines in the docs, fix some issues marked with the good first issue label. @danielroe is very quick to review PRs and very helpful if you need help with some implementations:)

[marabesi]

+1 on this one, I wonder if there are people with real use cases reported migrating from nuxt 2 to 3? Preferably step by step and not a big bang replacement.

[DenFin]

Not sure if this is appropriate here, but I've created a post on Reddit explaining superficially how we would like to approach the migration of a large website. I hope people can share their experiences in the comments, so we can gather information collectively

[Austio]

Added a discussion to consider moving the app to Security Maintenance Mode only for a few months into 2024 until Nuxt Bridge RC is out and people have had a chance to use it.

#23342

[NicoHof]

I still cannot find any information about the second point of the initial post.

Add migration guide from Nuxt Bridge -> Nuxt 3

We try to upgrade our nuxt 2 app to nuxt 3 right now and started with the bride approach.
I wondered what is left to do, if we eventually get in the future to the point when we did all chapters in "upgrade steps" here:
https://nuxt.com/docs/bridge/overview#upgrade-steps

There is no information about whats next to get finally to nuxt 3?

Using Nuxt Bridge, you can make sure your project is (almost) ready for Nuxt 3 and you can gradually proceed with the transition to Nuxt 3. (https://nuxt.com/docs/bridge/overview)

Docs say "Almost ready"

Am I missing something? What needs to be done when on nuxt bridge?

Maybe @danielroe can give some update to this topic?

[bew-devs]

That is exactly what I have done.
And it works fairly well :)

[dhaladitya108]

@bew-devs what are you exactly doing? creating a new nuxt3 project or directly upgrading nuxt2 to nuxt3.

[bew-devs]

What I did was :
First do a nuxt 2 -> Nuxt bridge migration
Then start a new Nuxt 3 bridge and copy paste content from the nuxt bridge migrated app into the new nuxt 3 app

[yoshrubin]

I preferred to not start a new project for nuxt3 but just update my existing project based on the Nuxt2 -> Nuxt3 upgrade guide so I could keep my commits and versioning

[dhaladitya108]

yes @yoshrubin that fair.

[navasfazil1004]

Hi, I have updated my nuxt from 3 to 3.10.1 and try to generate static files for my firebase hosting.
I am getting the following error.
ℹ Initializing prerenderer nitro 7:25:00 PM
ℹ Prerendering 10 routes nitro 7:25:04 PM
├─ /api/_content/cache.1707486890527.json (29ms) nitro 7:25:04 PM
undefined 7:25:04 PM
undefined 7:25:04 PM
├─ /200.html (176ms) nitro 7:25:04 PM
├─ /404.html (176ms) nitro 7:25:04 PM
├─ /stories (678ms) nitro 7:25:05 PM
├─ /corporate (678ms) nitro 7:25:05 PM
├─ /coursereviews (1113ms) nitro 7:25:05 PM
├─ /careergrowth (1129ms) nitro 7:25:05 PM
├─ /resources (1171ms) nitro 7:25:05 PM
├─ / (1791ms) nitro 7:25:06 PM
├─ /landing (1809ms) nitro 7:25:06 PM
✔ Generated public .output/public nitro 7:25:06 PM

ERROR ENOENT: no such file or directory, open 'D:\Navas\Client\Firoz\ivanooo\in.output\server\package.json'

[dhaladitya108]

It sounds like you haven't generated static files yet, so I'm not entirely sure about the specifics of your issue. However, I recommend upgrading to Nuxt version 3.6.0 as a first step. This way, we can methodically work through the changes in each version's release notes together. By doing this, we might be able to pinpoint exactly which updates are impacting your project.

[dhaladitya108]

release

[navasfazil1004]

Hi @dhaladitya108 , thanks for the reply.
I have udpated the nuxt version.
Actulaly there is no errors while generating. I am usind dynamic urls from post (Wordpress api). When I click on post and click refresh, the page returns 404. In my output/public folder the dynamic pages are not generating.

[navasfazil1004]

@ALL

[durga-kale]

Hi All,

I am currently migrating nux2 -> nuxt3. and came across weird issue when used express as server handler in nuxt3 platform.
The api returns 204 no content in the browser and in the terminal i could see the h3 event logged.

/server/middleware/index.ts

import app, {cmsRouter} from "shared_package"

app.use("/cms", cmsRouter);
const h3handler = fromNodeMiddleware(app);
export default h3handler;

/nuxt.config.ts
export default defineNuxtConfig({
serverHandlers: [
{ route: "/home/api/**", handler: './src/express/app/handler.ts', middleware: true }
],
});

H3Event {
is_event: true,
node: {
req: IncomingMessage {
_readableState: [ReadableState],
_events: [Object: null prototype] {},
_eventsCount: 0,
_maxListeners: undefined,
socket: [Socket],
httpVersionMajor: 1,
httpVersionMinor: 1,
httpVersion: '1.1',
complete: true,
rawHeaders: [Array],
rawTrailers: [],
aborted: false,
upgrade: false,
url: '/home/api/cms/alerts/uk/index/wide',
method: 'GET',
statusCode: null,
statusMessage: null,
client: [Socket],
_consuming: false,
_dumped: false,
originalUrl: '/home/api/cms/alerts/uk/index/wide',
[Symbol(kCapture)]: false,
[Symbol(kHeaders)]: [Object],
[Symbol(kHeadersCount)]: 40,
[Symbol(kTrailers)]: null,
[Symbol(kTrailersCount)]: 0
},
res: ServerResponse {
_events: [Object: null prototype],
_eventsCount: 1,
_maxListeners: undefined,
outputData: [],
outputSize: 0,
writable: true,
destroyed: false,
_last: false,
chunkedEncoding: false,
shouldKeepAlive: false,
maxRequestsOnConnectionReached: false,
_defaultKeepAlive: true,
useChunkedEncodingByDefault: true,
sendDate: true,
_removedConnection: false,
_removedContLen: false,
_removedTE: false,
strictContentLength: false,
_contentLength: null,
_hasBody: true,
_trailer: '',
finished: false,
_headerSent: false,
_closed: false,
socket: [Socket],
_header: null,
_keepAliveTimeout: 5000,
_onPendingData: [Function: bound updateOutgoingData],
req: [IncomingMessage],
_sent100: false,
_expect_continue: false,
_maxRequestsPerSocket: 0,
[Symbol(kCapture)]: false,
[Symbol(kBytesWritten)]: 0,
[Symbol(kEndCalled)]: false,
[Symbol(kNeedDrain)]: false,
[Symbol(corked)]: 0,
[Symbol(kOutHeaders)]: [Object: null prototype],
[Symbol(kUniqueHeaders)]: null
}
},
web: undefined,
context: {
_nitro: { routeRules: [Object] },
nitro: { errors: [] },
nonce: '4KnWvrLVJ1KvJE22XxJSTw==',
matchedRoute: { path: '/home/api/**', handlers: [Object], params: [Object] },
params: { _: 'cms/alerts/uk/index/wide' }
},
_method: 'GET',
_path: '/home/api/cms/alerts/uk/index/wide',
_headers: undefined,
_requestBody: undefined,
_handled: false,
fetch: [Function (anonymous)],
'$fetch': [Function (anonymous)],
waitUntil: [Function (anonymous)],
captureError: [Function (anonymous)]
}

Any help would be appreciated, Thanks in advance.

[dhaladitya108]

although I am not sure what you are trying to achieve.
app.use("/cms", cmsRouter); -- this isn't the way to do this in nuxt3

https://blowstack.com/blog/how-to-integrate-express_js-with-nuxt-app
https://dev.to/mihaiandrei97/nuxt3-express-api-bf5
You can refer to these.

I have one question though, why do you want to use express as the server handler here?

[durga-kale]

Hello @dhaladitya108, I wanted to use express as middleware but as per the documentation https://h3.unjs.io/guide/event-handler implemented the sever handler.
app.use("/cms", cmsRouter); -> cmsRouter is the express router which i am importing from the shared packages where the express code is written.

I have followed https://dev.to/mihaiandrei97/nuxt3-express-api-bf5 but that gave me 404 error.

[dhaladitya108]

@durga-kale I'm not sure about this 😐. Nuxt already uses nitro as its server engine, you may get the job done with nitro itself.
Otherwise try connecting with communities and seeking help.

[durga-kale]

@dhaladitya108 after catching all the routes as per api path i was able to get the response and issue is resolved :)