Nuxt Migration from 2 to 3 #19895
Replies: 14 comments 44 replies
-
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 🙏 |
Beta Was this translation helpful? Give feedback.
-
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:
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). |
Beta Was this translation helpful? Give feedback.
-
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:
Once I manage to use bridge instead of @nuxt/composition-api then I could be more helpful, but I am stuck there already. |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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 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:
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. |
Beta Was this translation helpful? Give feedback.
-
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 I have a list of my findings: Testing a moduleplaywrightThe 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-vitestLuckily we found Mocking composables and other importsWith vue 2 it was super easy to supply mocked plugins to your components by providing It would be super helpful if this becomes more fluent, perhaps something like:
Validating headIt's difficult to test anything that uses the Missing documentationIt 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. ConclusionAll 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 Thanks @danielroe and all the others for putting in all the effort! |
Beta Was this translation helpful? Give feedback.
-
Hi guys,
I try to do same on Nuxt3 migration but seems not work same any clue on how to serve data directly ? |
Beta Was this translation helpful? Give feedback.
-
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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:) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I still cannot find any information about the second point of the initial post.
We try to upgrade our nuxt 2 app to nuxt 3 right now and started with the bride approach. There is no information about whats next to get finally to nuxt 3?
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? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Hi All, I am currently migrating nux2 -> nuxt3. and came across weird issue when used express as server handler in nuxt3 platform. /server/middleware/index.ts import app, {cmsRouter} from "shared_package" app.use("/cms", cmsRouter); /nuxt.config.ts H3Event { Any help would be appreciated, Thanks in advance. |
Beta Was this translation helpful? Give feedback.
-
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:
In order to do this, we have a number of tasks before us:
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.
Beta Was this translation helpful? Give feedback.
All reactions