L'aventure Ember Initiative 🐹❤️ Semaine 10

Semaine 10 – Ember Inspector feat. Embroider

#web #emberjs #ember_inspector #vite #embroider #addons #blog_post

Je publie ce résumé avec quelques jours de retard, car je n’ai pas pu m’en occuper vendredi dernier, mais le voici. Malheureusement, ce pourrait être ma dernière mise à jour hebdomadaire pour l’Ember Initiative pendant un certain temps, à moins que l’Initiative ne reçoive davantage de soutien. Mais commençons par les bonnes nouvelles et revenons à ça plus tard.

Ember Inspector #

Exécution de la preuve de concept #

Mon objectif principal cette semaine était de faire fonctionner l’Ember Inspector pour une application Vite — en d’autres termes, faire tourner la preuve de concept de Chris de mon côté.

Vous devez avoir les deux branches de [Chris] (le côté ember.js et le côté ember-inspector) fonctionnant ensemble. En d’autres termes, vous devez pnpm link la branche mansona/ember.js à une application Ember que vous souhaitez 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.

Utiliser une version locale d’ember-source n’est pas trivial : ça nécessite de builder ember.js. Une section du guide de contribution est dédiée à ça. Notez que par pnpm link ../../path/to/ember-source, on entend le chemin vers votre dépôt local ember.js contenant le package.json et le dossier dist que vous avez construit. Personnellement, j’ai dû me battre avec mon lien local vers ember.js : j’étais bloquée par des erreurs sans rapport avec l’inspecteur, et pour avancer, j’ai dû commenter les invocations de composants dans le template de mon application Vite pour éviter qu’elles ne déclenchent des problèmes. Mais c’était tout ce qu’il fallait pour faire fonctionner la preuve de concept 🎉

En utilisant cette base, j’ai pu commencer à explorer le code de l’inspecteur et me familiariser avec les premiers problèmes que nous devons corriger. 💡 Le dépôt ember-inspector contient un dossier ember_debug, qui se construit en un script ensuite injecté dans la page principale pour créer le pont entre l’inspecteur et l’application. Un point bête sur lequel j’ai buté était la prise en compte des modifications locales que j’apportais au dossier ember_debug. J’ai dû exécuter pnpm build sur le dossier lui-même plutôt que de lancer la commande de build depuis la racine. Ce n’est qu’alors que mes modifications étaient appliquées lorsque j’utilisais pnpm serve:bookmarklet pour charger l’inspecteur localement.

Le brouillon sur Embroider #

Le résultat de la semaine est une PR sur le dépôt Embroider qui crée le même objet, emberInspectorLoader, que celui que Chris a créé côté ember.js dans la preuve de concept. L’approche n’était pas évidente, car il existe plusieurs façons de procéder.

• Un fichier virtuel classique ? Embroider inclut un pattern pour créer des fichiers virtuels comme vendor.js ou test-support.css, qui sont émis en tant que fichiers réels dans la construction Rollup. Je suis assez familière avec cette partie d’Embroider, car j’en ai écrit quelques-uns pendant l’Ember Initiative en 2024. Cependant, il y avait quelque chose d’étrange à utiliser ce système central pour une fonctionnalité de compatibilité avec classique, surtout avec l’espace de noms @ember qui n’est pas une chose “virtuelle” ; nous voulons finalement que @ember/debug/inspector-support soit fourni par ember.js. Nous avons donc décidé d’abandonner cette approche.

• Adaptateur de compatibilité ember-source Embroider “compat” est la partie d’Embroider qui gère la compatibilité avec les fonctionnalités classiques. Il inclut un concept d’adaptateur de compatibilité qui permet de corriger les addons. Ce système peut être utilisé pour créer un nouveau fichier dans les versions d’ember-source qui supportent Vite, de sorte que les utilisateur·rices de Vite de 3.28 à la dernière version aient ce script supplémentaire qui fournit emberInspectorLoader. En plus de la simplicité relative, un autre avantage de cette approche est que nous pouvons ajuster le script en fonction de la version d’Ember. Par exemple, Ember < 4.8 n’avait pas d’export pour @ember/enumerable/mutable, donc si l’utilisateur·rice utilise une version entre 3.28 (inclus) et 4.8 (exclu), il y a un objet utilisé par l’inspecteur que nous devons obtenir d’ailleurs. Le problème, cependant, est que les adaptateurs de compatibilité ne corrigent que les addons v1, et à partir de 6.1, ember-source est devenu v2, donc les adaptateurs de compatibilité ne couvrent pas tout ce dont nous avons besoin.

• Un plugin Vite dédié La dernière approche que j’ai essayée est un plugin Vite dédié, inspectorSupport(). C’est une version extra-simple des fichiers virtuels classiques. Si @ember/debug/inspector-support n’a jamais été résolu auparavant et finit par passer dans la fonction resolveId() du plugin, alors je le résous avec un identifiant spécifique, et la fonction load() pour cet identifiant retourne le script dont nous avons besoin. L’utilisation de cette approche en combinaison avec l’adaptateur de compatibilité pour la plage 3.28 -> 4.8 permet de résoudre @ember/debug/inspector-support pour chaque version.

L’article de blog sur l’audit des addons #

Lors de la Semaine 4, j’ai décrit comment j’ai utilisé l’API d’Ember Observer pour me faire une idée de l’état des 100 addons Ember les plus populaires.

Cette semaine, cet audit a été conclu par un article de blog : Getting ready for Vite! The status of the top 100 Ember addons. L’article de blog ne traite pas seulement des résultats de l’audit, mais aussi de son impact sur notre feuille de route pour l’Ember Initiative. Par exemple, grâce à cet audit, nous avons vu à quel point ember-css-modules et ember-test-selectors sont importants pour la communauté, ce qui explique pourquoi j’ai travaillé sur ces deux addons (principalement lors des Semaines 5 et 7).

De plus, l’article de blog inclut des sections clarifiant la situation autour de Webpack et FastBoot, alors si ça vous intéresse, n’hésitez pas à y jeter un œil.

Nous avons besoin de soutien #

Les trois premiers mois touchent à leur fin, et malheureusement, nous devons ralentir l’Ember Initiative. Nous travaillons activement à trouver de nouveaux sponsors pour financer le développement des 3 prochains mois. Vous pouvez nous aider à y parvenir :

• En partageant les publications de Mainmatter sur les appels à sponsor sur les réseaux sociaux.

• En parlant de l’Ember Initiative autour de vous et dans votre entreprise.

• En partageant votre expérience si notre travail vous a aidé à migrer votre application Ember vers Vite.

Nous avons accompli tant de choses en 10 semaines de travail. Je suis très enthousiaste quant à l’impact sur la communauté Ember, et j’espère sincèrement que l’Ember Initiative pourra continuer avec davantage de soutien.

Intro, Semaine 9, Petite pause