Comment migrer 100K lignes de code vers Typescript

computer science…Avec un Snapshot Test

Même lorsque l’on utilise les paramètres les plus basiques possibles, la migration d’un projet volumineux vers TypeScript, peut se révéler insurmontable. On est rapidement submergé par un nombre exorbitant d’erreurs.

➡️ Read in original version

Pour y remédier, la meilleure option semble être l’utilisation d’une combinaison de TypeScript et JS (en utilisant le flag allowJs). Mais en choisissant cette voie, vous prenez le risque de voir une grande quantité de code ne jamais être typé et pour cause : rien n’y incite.

Si vous exécutez TypeScript sur un grand projet après avoir renommé des fichiers, vous pouvez être confronté à quelque chose de ce genre:

Typescript migration

Potentiellement avec bien plus d’erreurs : ce projet a démarré avec 15 000 erreurs !

Malheureusement, pour la plupart des projets d’une certaine taille, vous rencontrerez des difficultés à migrer vers TypeScript en une fois.

En somme, quelles sont vos options ?

Technique de conversion Effort individuel Effort d’équipe Incrémentale – Convertir les fichiers modifiés Effort d’équipe – Checklist Incrémentale – Snapshot test
Rapidité
Qualités des résultats
Faible coordination d’équipe
Sans interruption
Extensible
Permet d’appliquer directement des règles strictes
Facilité d’ajout de règles plus strictes
Permet d’obtenir 0 Erreurs
Facilement réplicable avec de nouvelles règles

 

Réfléchissons.

Idéalement, vous souhaitez éliminer toutes les erreurs et disposer d’une méthode aisément reproductible pour éviter de nouvelles erreurs à l’avenir. Pour ce faire, la meilleure solution pourrait être de créer un snapshot test.

En substance, créer un snapshot test requiert le lancement d’un test qui exécute TypeScript et enregistre une capture de toutes les erreurs, ainsi que des noms de fichier et des numéros de ligne. Le test échouera à chaque fois que des lignes sont déplacées sur un fichier contenant des erreurs ou que de nouvelles erreurs sont ajoutées à la base de code, ce qui permet de se rappeler de corriger les erreurs récurrentes apparaissant lors d’ajouts ou de modifications au code. Automatisée, cette approche exigera peu de coordination d’équipe.

Il est aisé d’augmenter progressivement la rigueur de la vérification du code : l’approche est la même.

Pour résumer, le snapshot test est plus proche du code que n’importe quelle méthode de vérification et demande peu d’effort de coordination à une équipe.

 

Comment créer le snapshot test des erreurs TypeScript?

Cet exemple de code (ActiveViam/typescript-migration-demo) montre un exemple simple de création de snapshot test des erreurs TypeScript.

Voici comment cela fonctionne, à partir des 3 fichiers JS de départ suivants :

// add.js
export default function add(a, b) {
  a + b
}
// subtract.js
export default function subtract(a, b) {
  a - b
}
// example.js
import add from './add'
import subtract from './subtract'

add('1', 3, 'hello world')

subtract('1', 3, 'hello world')

Lorsque nous convertissons cet extrait en TypeScript après avoir modifié son extension de fichier et ajouté un fichier tsconfig.json , un certain nombre d’erreurs apparaissent dans le code:

Typescript tutorial

C’est à ce moment que vous devriez exécuter le snapshot test et en valider les résultats. Le snapshot des erreurs ressemblera alors à ceci :

Que se passe-t-il lorsque je corrige ou crée des erreurs supplémentaires ?

Lorsque vous corrigez les erreurs, vous pouvez exécuter yarn check-ts -u  pour mettre à jour le snapshot, vous devriez alors voir apparaître quelque chose de semblable à ceci:

typescript react

Si vous créer une erreur dans le code par accident, vous verrez quelque chose comme ceci:

typescript interface

A ce stade, si vous effectuez des PR reviews, votre correcteur rejettera probablement ce changement.

Utiliser ESLint (ou d’autres outils)

Cette technique s’applique à tout modèle pouvant être détecté à l’aide d’outils de vérification de la qualité du code. Par exemple, il est possible d’écrire des règles ESLint pour les mauvaises pratiques récurrentes spécifiques à votre base de code. Vous pouvez ensuite supprimer celles-ci progressivement en utilisant cette technique.

 

Conclusion

De toutes les techniques possibles pour migrer vers TypeScript, celle-ci est sans conteste celle qui offre le plus d’avantages.

GET IN TOUCH

Questions ? Want to know more about our solutions?




Follow us: linkedin twitter