L'aventure Ember Initiative 🐹❤️ Semaine 19

Semaine 19 – Le chemin vers v2 pour ember-scroll-modifiers

#web #emberjs #open_source #ember_scroll_modifiers #addon_v2 #migration_steps #guides

Cette semaine, j’ai eu deux jours de travail alloués à l’Initiative. Je suis ravie de dire qu’ils ont été bien utilisés, mais j’aurais aimé avoir plus de temps pour aborder un périmètre plus large. Heureusement, il existe un type de tâche qui s’adapte parfaitement à ~2 ou ~3 jours, et c’est la conversion d’un addon communautaire au format v2.

Conseils et apprentissages tirés d’ember-scroll-modifiers #

L’ordre le « plus facile » #

Tout d’abord, lorsque vous souhaitez migrer un addon classique vers v2, je vous encourage fortement à gérer la migration avec plusieurs PR. Vous pourriez avoir l’impression de perdre du temps, mais je suis convaincue que la confiance que vous et vos reviewers aurez dans la migration en vaut la peine. Puisque ember-scroll-modifiers a une structure assez standard et fournit des modifiers, la répartition des PR que j’ai faite est ma recommandation personnelle (⚠️ les commits sont importants) :

• https://github.com/elwayman02/ember-scroll-modifiers/pull/1268 – Utiliser le gestionnaire de paquets pnpm
• https://github.com/elwayman02/ember-scroll-modifiers/pull/1273 – S’assurer que la CI est dans un état décent
• https://github.com/elwayman02/ember-scroll-modifiers/pull/1274 – Séparer l’addon et la démo-app en deux packages distincts
• https://github.com/elwayman02/ember-scroll-modifiers/pull/1275 – (Optionnel) Démêler la démo (docs) et les tests
• https://github.com/elwayman02/ember-scroll-modifiers/pull/1276 – Convertir le package de l’addon à v2

💡 Notez que « Démêler la démo et les tests » n’est pas nécessairement critique si vos tests sont verts dès le départ. Dans ember-scroll-modifiers, cette étape était importante car les résultats des tests étaient trompeurs : ils échouaient à cause de l’outil de documentation et non à cause de l’addon lui-même.

Attention au guide de portage #

Si vous souhaitez convertir un addon à v2, vous pourriez naturellement consulter « Guide: Porting an Addon to V2 ».

J’ai peut-être déjà mentionné dans un précédent compte rendu hebdomadaire que la méthode qu’il présente est légèrement différente de la mienne : il propose une façon de séparer l’addon et l’application de test en une seule étape, et je pense qu’il est bien plus clair de déplacer toute la structure dans un package d’abord, comme je l’ai fait dans ce commit, puis de déplacer l’application de test ensuite, dans un commit séparé. Mais c’est une préférence personnelle, et ce n’est pas ce que je souhaite vous signaler ici.

Ce qui est important de noter, c’est que, au moment où j’écris ces lignes, ce guide de portage n’est pas à jour avec le dernier blueprint qui génère un addon v2 tout frais. Certaines dépendances ont changé, et la structure de monorepo a été abandonnée. Alors, devez-vous suivre le guide de portage ? Ou devez-vous créer un nouvel addon quelque part sur votre ordinateur pour étudier sa structure et faire de même ?

pnpm dlx ember-cli@latest addon my-addon -b @ember/addon-blueprint --pnpm

Pour ember-scroll-modifiers… j’ai fait un mélange des deux approches 🙈 (Oui, vous pouvez faire ça aussi 😬)

J’ai suggéré à Jordan Hawker (l’auteur) de conserver l’approche monorepo pour une raison : la démo-app est basée sur empress/field-guide, qui est incompatible avec Vite pour le moment. Par conséquent, la démo-app ne peut pas être facilement migrée vers Vite (et ni mettre à jour field-guide ni réécrire les docs avec une solution différente ne sont des options simples à mettre en oeuvre, en tout cas certainement pas avec mon budget de 2 jours). Et la dernière structure de blueprint d’addon supprime le monorepo en faveur d’une configuration Vite globale, donc aller dans cette direction était potentiellement problématique.

J’ai suivi l’approche monorepo décrite dans le guide de portage, tout en rapprochant le package de l’addon de ce que fournit le nouveau blueprint d’addon (par exemple, il utilise les configurations Babel du blueprint au lieu de celles héritées des guides de portage, etc.). L’idée principale est que chaque fois que le guide de portage disait : installez ceci, ou utilisez ce fichier comme exemple, j’ai plutôt regardé ce que fait le blueprint maintenant.

Je crains que ce soit, une fois de plus, mon dernier compte rendu hebdomadaire pour un moment. Hélas, je n’aurai aucun jour alloué à l’Ember Initiative avant la fin du mois prochain, et ce ne sera encore que quelques jours, donc je ne rédigerai peut-être pas de compte rendu. Je suis assez satisfaite de ce que j’ai pu faire, cependant. Quand on m’a notifiée que je n’avais plus que 2 jours, j’ai pu choisir quelque chose qui, je pensais, conviendrait, et je dirais que j’ai gagné mon pari : les PR ne sont pas toutes mergées pour l’instant, mais elles sont vertes, documentées, et toutes prêtes.

Intro, Semaine 18