L'aventure Ember Initiative 🐹❤️ Semaine 9

Semaine 9 – Un plan pour Ember Inspector

#web #emberjs #docs_writing #ember_inspector #vitejs #embroider #virtual_files

Cette semaine a été une semaine solitaire pour moi, puisque mes deux collègues et mon manager étaient en vacances. J’ai dû avancer sur tous les sujets que nous avions sur la table, et je me suis concentrée sur trois d’entre eux : améliorer ember-vite-codemod, préparer la communication sur l’audit des addons Ember, et travailler sur Ember Inspector.

D’abord, réécrire le README #

Comme tout·e développeur·se senior, je fus un jour junior. Mes souvenirs les plus traumatisants de cette période concernent une partie particulière de la résolution d’erreurs : deviner ce que les autres développeur·ses veulent dire lorsqu’iel·s écrivent des choses sur Internet. À un moment donné, il m’a semblé que leurs propos restaient flous exprès. Je soupçonnais un problème d’ego inconscient, du genre : « Si j’ajoute des explications plus détaillées sur quelque chose, ça signifie que je pense que ce n’est pas évident. Mais si d’autres développeur·ses pensent que je pense que ce n’est pas évident, alors qu’à leurs yeux c’est évident, alors iel·s vont penser que je suis incompétent·e. » Quelque chose comme ça. Je cherchais désespérément une réponse logique aux questions : « Pourquoi vos docs sont-elles si MAUVAISES ? Pourquoi vous ne voulez pas EXPLIQUER ? Vous avez écrit plein de trucs ici, mais quelle est la CONCLUSION ? Que voulez-vous DIRE ? Qu’est-ce qui ne va pas chez VOUS ? »

Presque une décennie plus tard, je ne suis plus aussi en colère contre toute la communauté dev. La raison principale est que j’ai appris suffisamment de choses pour comprendre bien plus souvent ce qu’iel·s essaient de dire, et je peux généralement suivre les docs de A à Z 🎉 Mais j’ai encore parfois du mal. Maintenant, même sur des docs qui me semblent globalement assez bonnes, chaque fois que je ne comprends pas une ligne immédiatement, chaque fois que je dois expérimenter un peu pour arriver à « ah, ok, c’est ça qu’iel veut dire »… J’ai une pensée émue pour la moi junior qui aurait simplement jeté son ordinateur par la fenêtre et tout abandonné pour aller élever un troupeau de chèvres dans les collines de l’Ardèche. Et je réécris les docs.

Vous n’avez que de bonnes raisons de réécrire les docs :

• C’est le type de contribution open source le plus facile. Vous modifiez simplement un fichier markdown, c’est 100 % sûr, vous ne allez pas détruire le monde.
• Si vous n’avez pas compris quelque chose immédiatement, il y a certainement d’autres développeur·ses qui ne le comprendront pas du tout. Votre retour a de la valeur, et si quelqu’un vous répond « Pff, mais c’est évident », alors cette personne est le problème ; vous n’êtes pas le problème.
• Si vous n’aimez pas tellement aider les autres (aucun souci), alors aidez-vous vous-même. La prochaine personne qui lira ce document après vous pourrait être vous, huit mois plus tard, sans aucun souvenir de ce qui vous avait posé problème.

Bref, j’ai ouvert une PR pour améliorer le README de l’ember-inspector.

Ember Inspector #

Après avoir creusé un peu dans le code de l’Ember Inspector, Chris (mansona sur GitHub) et moi avons élaboré un plan plus précis.

• Preuve de concept : Implémenter un support Vite approximatif en utilisant des modifications de code dans ember-inspector et ember.js. En résumé, le côté inspecteur doit lire un nouvel objet fourni par le côté Ember, car il ne peut plus compter sur les modules AMD et le fichier baril d’Ember, qui est obsolète. C’est déjà fait : Chris a ouvert deux PR de brouillon dans chaque dépôt et a réussi à faire fonctionner le tout.
• Solution rapide : Inclure des modifications dans ember.js est un processus long qui implique la rédaction d’une RFC pour concevoir et discuter de la solution finale. En attendant, les utilisateur·rice·s de Vite sont coincé·es avec un inspecteur non fonctionnel. Pour résoudre ce problème, nous voulons implémenter une solution temporaire en utilisant le système de fichiers virtuels d’Embroider. Nous voulons rendre Embroider capable de retourner le contenu que ember.js devrait fournir à l’inspecteur ultimement. C’est ce que j’ai exploré cette semaine, j’ai une PR de brouillon sur le dépôt Embroider qui s’exécute partiellement mais nécessite encore du travail.
• RFC : Sur la base de la preuve de concept, rédiger une RFC pour décrire le nouveau protocole permettant à l’inspecteur de communiquer avec ember.js.
• Implémentation de l’inspecteur : À partir de la preuve de concept, continuer à creuser dans le code de l’inspecteur pour comprendre ce qui manque encore, ce qui peut être nettoyé, ce que le concept de verrouillage de versions signifie exactement… et obtenir la PR finale pour implémenter le support de Vite.

Une chose à laquelle je ne m’attendais pas, cependant, c’est à quel point il serait compliqué d’essayer le prototype de Chris. Pour le faire fonctionner, il faut avoir ses deux branches (le côté ember.js et le côté ember-inspector) qui tournent ensemble. En d’autres termes, il faut pnpm link la branche mansona/ember.js à une application Ember que vous voulez inspecter, servir cette application Ember, exécuter localement la branche mansona/ember-inspector, et lancer le script pour charger cet inspecteur local dans l’application que vous servez. Ça aurait été faisable sans ces erreurs Ember obscures que j’obtiens avec mon pnpm link d’ember.js, et malheureusement, je ne peux pas encore documenter les apprentissages dans ce compte rendu hebdomadaire, car je n’ai pas encore trouvé la réponse.

Pas la semaine la plus facile de toutes, il y a eu beaucoup de changements de contexte, mais au final, je suis plutôt satisfaite du résultat : quatre améliorations livrées sur ember-vite-codemod, un brouillon pour Ember Inspector à poursuivre quand Chris sera de retour, et un article de blog en préparation sur l’audit des addons qui pourrait sans doute être publié d’ici la fin de la semaine prochaine. Voyons si la semaine 10 pourra être celle de la sortie de notre support Vite temporaire pour l’inspecteur.

Intro, Semaine 8, Semaine 10