Comment nous avons migré de Vue ou Vue 3

Il y a environ un an, nous avons finalement migré de Vue 2 vers Vue 3. C'était 6 mois avant sa fin de vie officielle. À l'époque, notre application comptait environ 100 pages et 300 composants, et utilisait certaines des dépendances classiques liées à Vue : Vue-router, Pinia (et Pinia ORM), Vue-i18n, TipTap, ElementUI (ElementPlus pour Vue 3)

Voici quelques conseils qui nous ont aidé. Comme Vue 2 fonctionne toujours plutôt bien, vous feriez mieux de prendre le temps de faciliter la migration au lieu de la précipiter, de casser votre application et de détruire votre moral !

---

1️⃣ Avant de commencer

Avertir les autres

Les choses vont certainement se casser, même un peu. Tu ferais mieux de t'assurer que tout va bien avec les autres équipes.

Mise à niveau vers la dernière version de Vue 2.7

Évidemment, comme la plupart des nouveautés sont disponibles dans Vue 2.7, et rétrocompatibles, il est important de rattraper son retard si ce n'est pas déjà fait. Lors de la migration vers Vue 3, vous pourrez toujours profiter de ses fonctionnalités. L'étape pour migrer sera également plus petite.

Prends le temps

Cela peut représenter un travail assez important, il vaut donc mieux anticiper pour atténuer le risque sur une longue période. En plus, cela nous a aidé (les développeurs) à garder le moral ! Prévoyez quelques semaines, voire quelques mois, car vous savez quand vous commencez, mais vous ne savez pas quand vous finirez... Enfin, mieux vaut y consacrer du temps chaque semaine, pour qu'une éventuelle panne ne soit pas désastreuse. 🎜>

Créer une équipe

Ne comptez pas sur un seul développeur si possible, car c'est une tâche épuisante. De plus, vous avez besoin de retours rapides et de boucles de fusion, car de nombreux changements affecteront l'ensemble de la base de code et pourraient créer des conflits au quotidien. C'est déjà assez dur sans avoir à gérer ça !

Migration pilotée par les tests

La moitié du temps sera consacrée à tester l'ensemble de l'application, vous feriez donc mieux de l'automatiser le plus possible. D'après notre expérience :

Les tests unitaires ne sont pas très utiles, car ils testent généralement des choses qui ne sont pas vraiment liées à Vue (uniquement des fonctions "pures JS" par exemple), donc nous ne nous sommes pas concentrés sur eux
Les tests de composants avec vue-test-utils ont été difficiles à migrer, nous avons même dû désactiver certains d'entre eux
Les tests de bout en bout étaient les plus précieux car ils ne sont liés à aucun composant interne de JS ou Vue et échouaient dès qu'une erreur était supprimée dans l'application

En conclusion, le mieux est de créer ce qu'on appelle un "smoke test", dans lequel vous naviguez simplement dans l'application avec le scénario le plus basique auquel vous pouvez penser. Gardez-les simples, pour qu'ils soient rapides, car plus tôt vous pourrez les faire fonctionner, plus ils seront utiles. Point bonus s'ils s'exécutent avant la fusion (dans un CI par exemple).

Tapez tout

TypeScript a un peu aidé, mais sa prise en charge dans Vue 2 est encore médiocre. Utiliser TypeScript est toujours une bonne idée, mais cela pourrait ne pas être très utile ; Une fois que vous utiliserez Vue 3, la syntaxe de configuration sera votre meilleure amie !

Tout pelucher

C'est évident, mais beaucoup de changements vont se produire dans le code, tout comme beaucoup d'erreurs. Un simple ESLint / Prettier peut faire gagner beaucoup de temps. Si vous les avez déjà, vous pouvez consulter les nouvelles règles pour Vue 3 pendant votre migration : https://eslint.vuejs.org/rules/

Utiliser Vite

Nous avions déjà migré de Webpack vers Vite avant de commencer à migrer Vue, donc je ne suis pas sûr que cela aide beaucoup, mais comme c'est la norme claire aujourd'hui, certains plugins peuvent même ne pas donner d'instructions pour la mise à niveau avec Webpack. Je suppose qu'il est plus sûr de le faire en premier car Vite prend en charge Vue 2, mais à l'inverse, l'écosystème Vue 3 pourrait ne pas prendre en charge Webpack.

---

2️⃣ Petits pas d'abord

L'objectif est d'avoir le moins de changements possible lors de la mise à niveau de Vue elle-même.

Dépendances de mise à niveau

Jetez un œil à chaque dépendance liée à Vue que vous utilisez et vérifiez s'il existe une version prenant en charge à la fois Vue 2 et Vue 3, et effectuez une mise à niveau vers celle-ci. Vue-demi a aidé de nombreux responsables de plugins à y parvenir, il y a donc de fortes chances qu'il soit disponible.

Par exemple, vous souhaiterez peut-être migrer de Vuex vers Pinia, qui prend en charge les deux versions (Vuex nécessite encore une petite migration) et est de toute façon le nouveau standard.

Remplacer les dépendances

Pour les autres dépendances, vous souhaiterez peut-être vérifier si une alternative moderne pourrait répondre à vos besoins. Par exemple, nous avons remplacé vue-mq par vue-use.

Monkeypatch en cas de besoin

Nous avons dû être pragmatiques, donc comme certaines migrations étaient plus difficiles que d'autres, nous avons fini par créer une petite couche d'abstractions pour y remédier. Par exemple, nous avons eu du mal avec vue-i18n v9 qui apporte des changements radicaux (parfois non documentés). Nous avons donc finalement créé un assistant qui expose une version personnalisée de $t pour éviter d'avoir à réécrire chaque composant (car cette fonction la plus utilisée n'accepte désormais plus les valeurs "nulles" sans aucune raison). En d’autres termes, ne soyez pas trop perfectionniste !

---

3️⃣ Commencer la migration

Maintenant, le dur travail commence. Tout ce que nous avons fait auparavant soulagera la douleur. Il n'y a pas de magie ici, ce sera probablement la partie la plus difficile de la migration.

Change tout, mais rien

Remplacez Vue 2 par Vue 3 par le "migration build" (également appelé mode compat) en suivant les instructions.

Désactivez tous les indicateurs disponibles pour que l'application fonctionne presque comme avec la version 2.

Vérifiez qu'aucune modification majeure n'affecte votre application ou corrigez-la.

Petits pas

Activez chaque indicateur de manière incrémentielle et testez minutieusement l'application. Si certains composants sont trop difficiles à migrer, gardez à l’esprit que vous pouvez remplacer son option de compatibilité ; il vaut donc mieux tout fusionner mais conserver quelques composants pour migrer plus tard au lieu d'attendre que l'ensemble de l'application fonctionne maintenant. N'essayez pas de tout réparer d'un coup, laissez passer quelques jours pour pouvoir détecter les bugs (et recharger votre santé mentale).

De grands pas

Certaines dépendances ne fournissent cependant pas de raccourcis. Dans notre cas, la migration de notre bibliothèque d'interface utilisateur d'ElementUI (Vue 2) vers ElementPlus (Vue 3) était difficile et ne pouvait pas être divisée en étapes plus petites. J'ai entendu dire que c'était encore plus difficile pour Vuetify. Pour cela, vous devrez être fort, patient et prendre le temps de tout faire en même temps. Prévoyez peut-être une semaine complète dans le calendrier de votre équipe !

N'oubliez pas que vous pouvez toujours remplacer le comportement de compatibilité de chaque composant que vous importez au moment de l'exécution :

import { ElButton } from 'element-plus'

ElButton.compatConfig = {
  FEATURE_ID_A: true // features can also be toggled at component level
}

Dernière étape

Une fois que chaque indicateur a été activé, il est temps de supprimer la version de migration. J'espère que vous ne découvrirez pas de nouveaux problèmes inattendus d'ici là !

N'oubliez pas de célébrer, vous l'avez mérité ! ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!