How to migrate a large app to Vue 3
Vložit
- čas přidán 21. 08. 2024
- Alex Van Liew presents “How we migrated our HUGE app to Vue 3” at VueConf US 2022. For more vue js tutorials on migrating from Vue 2 to Vue 3, check out our courses 👉 www.vuemastery...
Ready to master Vue.js? With weekly Vue js tutorials on the latest topics, and exclusive content with Evan You (the creator of Vue), Vue Mastery is the ultimate learning resource for Vue developers to level-up their skills. Watch more free Vuejs tutorials 👉 www.vuemastery...
Get in touch 👉 team@vuemastery.com
0:09 Introduction
1:23 Why migrate now (or at all)?
3:57 Scale
4:52 Technologies
5:56 @vue/compat
7:38 Phase 1: Prepare
13:50 Phase 2: Upgrade
30:39 Phase 3: Deploy
32:45 Thanks!
33:45 Q+A
I upgraded three vue2 projects, One of them had around 1800 components. also the upgrade included migrating to vite + using script setup + defineProps with Typescript.
After these intense experiences, I have to say there is no shortcut to do it, how I prefer doing it:
1- Start by droping webpack & configure vite build & hmr. Save this progress in a separate branch & create a new branch from this one to do the component upgrade in it.
2- Update vue packages, delete the components folder and start pulling the components file by file & upgrade them. (Better to start with your style-guide components like inputs/selects.. because they don't depend on other components and build your way up till you finish your first page then you can test it. If you are using vue router, just comment out all the routes and uncomment once your page is ready.
3- keep doing this until you finish all the pages. On your way to the last page, you will find yourself not just refactoring to vue3 but you are also extracting re-used functionalities into separate files, (autocomplete.ts, dragFile.ts..) and end up writing less code.
4- Update your testing tool config and make sure all your unit tests are green. Migrating to Vitest can be tackeled alone afterwards.
From Dev experience point of view, I think this way is the best as you easily track your progress, apply best practices and you can split the work in the team (each individual can select a set of components and start working with it and then they communicate what they did to the rest of the team in the end of each day).
It took one month (1800 components 8h/day 5d/week) and a half to get everything runing & start bug hunting. So its kinda of time-consuming + it will block new features.
Thanks a lot for sharing your practical experience.
Thank you for the tip!
You advice it is better approach than working under vue@compat ?
If this is the best way to do it, it says a lot about how the Vue team does not care about their user base. I will never use this library for any critical work again.
The change is so big that I am considering a rewrite in React. The frontend churn is too much
Imagine if the website I deployed 10 years ago stopped working because browsers dropped support for certain features. Fortunately, this isn't the case for any websites regardless of when they were deployed. It's disappointing that Vue isn't written in such away that's always backwards compatible. No one wants that extra work to migrate to a newer version 🙄
This is not just a Vue issue. The JavaScript landscape follows this crazy behavior. Childish and unprofessional mindset.
Also for us the i18n story was quite painful and of course Vuetify is a big mess. I do not know what is really worth it sometimes from my experience, just rewrite everything to React or migrate to Vue 3 ;)
Seems this didn't matter. This had zero information about vue-property-decorator and was actually a small app.
We should have documented our change. 2100 Vue components, with 230,000 lines of code changed.
This video convinced me to migrate to React altogether... :(
A little late for this I am afraid.. Guess what we just finished doing? and I mean "just".. We been rewriting for 3 months. We are in the "Linting is getting OUT OF MEMORY" phase of the migration. So we can run the app in dev, but not been able to build yet. Sad times..
PS: there is a job open for anyone who wants to review a 230,000 Pull Request?
@@ColinRichardson Says alot you didn't perform the rewrite on a seperate branch, smaller commits, via bottleneck working.
GL to you, a lesson learned for next time maybe.
@@internetoldie it was on a separate branch. The only work done on the main dev branch were contractually obligated features and hot fixes.. And smaller commits would not have helped. Our Vue2 was based on `vue-property-decorators` (eg, class base vue). 100% incompatible. Throw in the fact that it's a 41 project interdependent monorepo.. It was either we do it all in 1 go, or don't do it at all.
Well, I guess we could have re-wrote the app slowly over time to be Vue2-property-decorators to Vue2-object-api and then upgrade to Vue3-object-api, fix whatever breaks, and then Vue3-object to Vue3-composition-api.. but that would have been on the orders of years to do. And basically be 2 full re-writes with a bug fixing episode in the middle.
But we managed to do it in 3 months, or I guess 15-man-hour-months.?? man-hour-months?? man-months?? Not sure the exact term there.. regardless that no way includes out of hour working.. I mean, I do a fair bit (I'm actually still doing some as we speak) but one of my co-workers is a machine.. I swear he was working 26 out of every 24 hour days.. He seemed to invent new time, just so he could use it migrating..
But now struggling with linters running out of memory, we solved some of it but splitting up the linters. though we had to disable some rules entirely..
We have had to do some rules (on-mass) .. stuff like, only defining refs after all computed and methods, because we have some "initialising" of the refs that need data from computed values.. wasn't a problem in class-vue structure, but in composition, we have had to be strict.. and we only found out about this being a problem AFTER we had changed all the files...
Thankfully I was able to write a pretty comprehensive regexp powered automation script to gather up all the parts and put them in the correct spaces.. but still a lot of manual fixing going on..
But it's getting there..
Though, I just thought of another test I can do to ensure there isn't a hidden gotcha hiding somewhere, so I am gonna go write that up now incase I forget..
(Sorry about the essey)
@@ColinRichardson Sounds like a sucky situation to be in brother!
Don't ever work more than your contractually obligated to, never worth it.
Sounds like there were ALOT of managers involved in that project!
Best, A
Where did they officially announce that vue2 support stopped?
I think it was in Evan You's talk: czcams.com/video/3QPp_DlcZpM/video.html
There should never be breaking changes. All of these painful framework upgrades just bolsters the value of running vanilla.js which never necessitates special workflows, a network of dependencies, or breaking changes.
With all due to respect, but I don't think this is the right way. In this way you will endup having the latest version of Vue 3 but not using Vue 3 as it should!
You will endup using Vuex which is not the recommended library. Pinia it is.
You will endup with Options API syntax. If you read through the docs you will see that Options API is discouraged. Script setup is the new way.
You will endup using Webpack and miss the DX of Vite but also the whole community behind it like Vitest, Auto-import-components, VueUse, Cypress Component Testing etc. Those can be added with Webpack but in my experience with Webpack all these are buggy whereas with Vite it just works.
In general, you will end up with using Vue 3 but still everything looking Vue 2-ish. Since Vite and Vue 3 the way we write apps has changed for the better (Pinia, Tailwind, Vite, Vitest, Historie, Cypress etc) and if you still use the old technologies then guess what. You will stay behind and then you will have to re-write everything in order to catch up. So it will be like 2 or 3 times migration.
Sorry for saying that but to me it doesn't sound like the right way of doing things. Personally I would prefer a re-write of the application. If might sound scary but it's actually not and companies should accept and understand innovation and go all-in to re-write. Vue 3 and script setup came because Evan You is always pro-innovation.
if your company can afford to halt development and have everyone work on a rewrite, more power to you. in my company, and in most companies, that is not an option and tbh it delivers very little value to the customer anyway. yes, you do need to go and integrate those new libraries and features - but you would have to do that anyway in a rewrite and the more progress you can show incrementally, the better off you are.
Sure. Let's rewrite the entire application every 3-5 years just because the Vue team does not care about backwards compatibility. Sound like a great idea!