Semaine 7 – La semaine courte
#web #emberjs #embertestselectors #babel #babelconfig
Cette semaine a été très courte pour l’Ember Initiative, car nous avions un événement d’équipe chez Mainmatter. J’ai essayé d’avancer sur mes tâches, mais je n’ai pas vraiment pu terminer quoi que ce soit.
ember-test-selectors pour Vite #
ember-test-selectors est un addon géré par Mainmatter qui fait partie des 100 addons les plus populaires. Puisqu’il s’agit d’un addon populaire, nous devons le migrer vers le monde V2, comme nous l’avons déjà fait pour ember-simple-auth, ember-cookies ou ember-promise-modals.
L’addon classique fonctionne pour Vite… #
ember-test-selectors est ce genre d’addon classique qui agit au moment du build et, par conséquent, n’est pas un bon candidat pour une migration vers v2 “tel quel”.
ember-test-selectors repose sur une option booléenne qui signifie “supprimer” ou “ne pas supprimer” les attributs data-test-* des templates. Lorsque l’option est true, l’addon construit un plugin Babel et l’ajoute à la liste des processus à exécuter. Il existe deux plugins Babel différents : le “principal” supprime les attributs data-test-* dans les templates, et le second supprime également les propriétés data-test-* des objets JS.
@embroider/compat est la partie d’Embroider chargée de faire fonctionner les addons classiques dans les applications Vite quand c’est possible. Entre autres choses, il génère une liste de plugins “Babel compat” à partir de tous les plugins ajoutés par les addons classiques, et ces plugins “Babel compat” sont ajoutés dans le babel.config.mjs de l’application Vite via les fonctions babelCompatSupport et templateCompatSupport. @embroider/compat est capable de réécrire correctement le comportement d’ember-test-selectors. Les plugins Babel construits par l’addon sont ajoutés à la configuration Babel de l’application Vite en utilisant la fonctionnalité “Babel compat”. En d’autres termes, l’utilisation de l’addon classique ember-test-selectors ne bloque pas votre migration vers Vite.
Cependant, si vous partez d’une application Vite et que vous souhaitez optimiser les performances en évitant que @embroider/compat ne s’exécute, alors ember-test-selectors doit proposer une solution.
…mais on a besoin d’une solution qui ne repose pas sur les addons compat #
Le monde V2 diffère du monde classique sur deux aspects : les addons v2 n’impactent pas la pipeline de construction ; l’application est responsable de la configuration (par exemple, la configuration Babel). Avant, on avait un addon classique qui ajoutait un plugin Babel au pipeline ; maintenant, tout ce qu’on veut, c’est que ce même plugin Babel soit ajouté directement au babel.config.cjs. Puisque l’application est responsable de la configuration, le plugin Babel n’a pas à se soucier du contexte externe (est-ce un build de production ou de développement, veut-on forcer la suppression, etc.). À la place, on documente comment les développeur·ses peuvent configurer Babel pour avoir le comportement par défaut (suppression en production) et on les laisse libres de modifier cette configuration s’iel·s ont des besoins très spécifiques.
Pour résumer, le plan est le suivant :
- Refactoriser la structure d’ember-test-selectors en un monorepo qui sépare l’addon classiques des tests.
- Séparer les plugins Babel (strip-test-selectors et strip-data-test-properties) de l’addon classique et faire en sorte que l’addon classique les installe.
- Créer une vite-app dans le dossier de tests du monorepo et installer le package strip-test-selectors pour exécuter des tests sur la configuration Babel.
À propos des tests #
Un aspect délicat à gérer avec ember-test-selectors est le test. Puisque la suppression des data-test-* ne se produit qu’en production, les tests qui vérifient la suppression échoueront s’ils sont exécutés dans le navigateur à partir d’un build de test. Dans la version classique d’ember-test-selectors, la variable d’environnement STRIP_TEST_SELECTORS était utilisée pour modifier le comportement de l’addon : la suppression avait lieu même dans un build de test si la variable était true, donc selon sa valeur, le bon ensemble de tests (il supprime ou il ne supprime pas) s’exécutait.
Il est tout à fait possible et légitime d’utiliser une telle variable d’environnement dans la configuration Babel de la vite-app utilisée par le monorepo pour les tests. Après tout, nous voulons tester le comportement du plugin strip-test-selectors, pas le comportement de la configuration Babel. Mais puisque nous voulons expliquer aux développeur·ses comment iel·s peuvent configurer la “suppression uniquement en production”, nous pourrions aussi considérer comme légitime de baser le test sur ce scénario spécifique, production vs développement. Tester le mode développement en CI est un peu plus compliqué, cependant, car nous devons démarrer un serveur de développement Vite.
Le test en mode développement devrait probablement être considéré comme une amélioration, séparée de l’introduction du plugin Babel strip-test-selectors.
Embroider 4 a finalement été publié cette semaine, nous sommes sur de bons rails pour faire de Vite le choix par défaut pour les nouvelles applications Ember. C’est pourquoi le travail sur les 100 addons les plus populaires est si important, car nous ne voulons pas que les nouvelles applications dépendent de l’installation d’addons classiques. Ce compte rendu hebdomadaire a été écrit depuis le train, j’ai fait de mon mieux ;)