Semaine 6 – Début de la mise à jour d’ember-test-selectors
#web #emberjs #migrationStrategy #embercssmodules #emberscopedcss #monorepo #embertry
Cette semaine a été une semaine de transition dans mon aventure Ember Initiative. Je passe d’un sujet à un autre, ce qui me donne une fausse impression d’inachèvement qui ne reflète pas vraiment l’avancement des choses. Ma semaine de 3 jours en résumé : j’ai terminé le chemin de migration de ember-css-modules vers ember-scoped-css, j’ai commencé à travailler sur la migration d’ember-test-selectors vers v2, et j’ai géré quelques issues sur ember-vite-codemod.
Le chemin de migration pour ember-css-modules est publié #
J’ai passé la majeure partie de la semaine 5 à travailler sur le chemin de migration pour se débarrasser de ember-css-modules ; l’article de blog est en ligne : Get ready for Vite, migrate from ember-css-modules. Je suis plutôt satisfaite de sa structure et de l’approche par dépôt que j’ai utilisée, ce qui pourrait devenir un modèle à réutiliser à l’avenir.
L’objectif principal de ce travail était de fournir aux développeur·ses un moyen de se débarrasser de ember-css-modules fichier CSS par fichier CSS. Diviser le travail en plusieurs petites PR est en effet une bonne pratique pour faciliter les revues et gérer les migrations importantes en toute confiance. À ce propos…
La meilleure façon de transformer un addon classique en monorepo ? #
Si vous voulez convertir un addon v1 classique en v2, une première PR devrait consister à refactorer le dépôt en un monorepo qui sépare l’addon classique et l’application dummy en deux packages distincts. Vous ne changez pas la manière dont les choses fonctionnent ; vous ne modifiez que la structure du dépôt.
Expliquer comment procéder est l’objectif du Guide: Porting an Addon to V2, Part 1: Separate Addon from Dummy App. J’ai moi-même utilisé ce guide par le passé (pour migrer ember-promise-modals vers v2) et j’ai même contribué à clarifier quelques points qui m’avaient posé problème. Et lorsque j’ai réutilisé ce guide pour ember-test-selectors, qui a une hiérarchie légèrement plus complexe, je me suis rendu compte que…
Le guide “Porter un Addon vers la V2” ne me proposait pas la méthode la plus simple pour avancer, et il a été très intéressant d’arriver à cette conclusion.
La meilleure façon de procéder pour moi est d’abord de créer un monorepo à package unique : je structure le monorepo avec uniquement mon package d’addon v1 dans l’espace de travail. Cette étape me permet de commencer avec une racine ultra-propre : un tout nouveau package.json privé, aucune configuration ESLint confuse, des commandes scripts qui ciblent le package de l’addon, etc. Et une fois que ça fonctionne, je peux commencer à créer de nouveaux packages à partir de zéro (test-app, node-tests…) et y copier ou déplacer le contenu du package de l’addon v1. Ça permet une approche plus progressive où je peux tester les commandes de lint et de test pour chaque nouveau package afin de m’assurer de ne rien oublier.
Un petit détail concernant ember-try #
Lorsque j’ai créé le monorepo pour ember-test-selectors et que j’ai poussé mon travail sur GitHub, toutes les matrices de versions d’Ember échouaient à cause de “ember-try config not found”. Au début, j’ai pensé avoir fait une erreur dans le workflow CI : peut-être que le répertoire de travail n’était pas correctement défini ? Mais je ne voyais pas le problème ; le workflow semblait correct.
J’ai finalement compris que l’option useVersionCompatibility invalidait la configuration d’ember-try. Cette option ne doit être définie que lorsque ember-try est utilisé pour tester un addon contre plusieurs versions d’Ember :
/*
Si cette option est définie sur true, la clé versionCompatibility sous ember-addon dans package.json sera utilisée pour
générer automatiquement des scénarios qui fusionneront avec ceux de ce fichier de configuration.
*/
useVersionCompatibility: true,
Puisque j’ai restructuré le dépôt pour avoir une application Ember simple test-app complètement séparée de l’addon classique, j’aurais dû supprimer useVersionCompatibility. Mais au lieu de me signaler une configuration invalide, la CI m’indiquait simplement “ember-try config not found”.
Nous avons accompli tant de choses en 6 semaines, et il reste encore tant à faire. Je suis plutôt satisfaite de ma vitesse de croisière jusqu’à présent : je parviens à gérer les issues laissées sur ember-vite-codemod tout en consacrant la majeure partie de mon temps aux objectifs principaux. J’aimerais oser espérer que la semaine prochaine sera celle où j’aurai terminé la mise à jour d’ember-test-selectors, mais je ne serai pas aussi audacieuse, car ce sera une semaine très courte (nous avons un événement d’équipe chez Mainmatter). Il ne fait aucun doute que je pourrai travailler sur quelques nouvelles améliorations pour ember-vite-codemod. Je ne le répéterai jamais assez : l’Ember Initiative est très importante pour toute la communauté Ember, notre équipe accomplit des choses incroyables pour le framework, et nous avons besoin de votre soutien pour continuer. Merci de contacter Mainmatter.