L'aventure Ember Initiative 🐹❤️ Semaine 8

Semaine 8 – Une nouvelle version pour ember-test-selectors

#web #emberjs #embertestselectors #pnpm #workspaces #babel #viteplugins #rollupplugins #emberinspector

ember-test-selectors 7.1.0 est disponible, ainsi que strip-test-selectors 1.0.0. Après avoir clôturé ce sujet, j’ai aussi pu m’intéresser à quelques issues sur ember-vite-codemod et faire du pair avec Chris sur notre prochain grand chantier : faire fonctionner Ember Inspector avec Vite.

Astuces tirées d’ember-test-selectors #

À propos de workspace:* #

ember-test-selectors est désormais un monorepo avec la structure suivante :

• ember-test-selectors : l’addon classique qui existait auparavant
• strip-test-selectors : les fonctions de transformation que vous pouvez configurer directement dans votre config Babel lorsque votre application utilise Embroider+Vite
• tests :
  • classic-app : teste la compatibilité de l’addon classique
  • node-tests : tests unitaires pour le plugin qui supprime les data-test-* des objets JS
  • vite-app : teste la configuration pour strip-test-selectors

Travailler avec des monorepos nécessite de maîtriser le concept de workspaces. Pour simplifier, c’est un protocole qui permet de déclarer les différents packages contenus dans votre monorepo.

Si vous avez déjà exploré un monorepo d’addon v2 utilisant pnpm, vous avez peut-être vu la syntaxe "my-v2-addon": "workspace:*" dans le package.json de l’application de test. Cette syntaxe signifie « utilisez la version locale de my-v2-addon, quelle qu’elle soit », donc vous n’avez pas besoin de gérer manuellement les mises à jour de version à l’intérieur d’un monorepo.

Ce que vous ne savez peut-être pas, cependant, c’est que ce concept est ce que pnpm appelle les alias de workspace, et qu’il y a une chose très importante à savoir à leur sujet : les alias de workspace sont interprétés et remplacés lors du pnpm publish. Ça signifie que tant que vous utilisez pnpm publish pour publier vos packages publics, vous pouvez utiliser en toute sécurité workspace:* à l’intérieur d’un package public qui dépend d’un autre package du monorepo (par exemple, ember-test-selectors a une dépendance à strip-test-selectors).

Utiliser Babel dans une application Vite #

La nouvelle documentation pour strip-test-selectors explique comment configurer Babel dans votre application Embroider+Vite pour reproduire le comportement de l’addon classique. Si vous avez une application Embroider+Vite, vous avez nécessairement déjà un fichier babel.config.cjs. C’est forcément le cas, car toute application Embroider+Vite fraîchement créée repose sur des plugins Babel dès le départ, ça fait partie du blueprint de l’application.

Vous êtes-vous déjà demandé comment le babel.config.cjs finit par être utilisé, cependant ? Si vous générez une simple application Vite avec pnpm create vite, elle n’utilisera pas Babel par défaut ; vous devez indiquer à Vite que Babel doit être exécuté à un moment donné. La réponse se trouve dans vite.config.mjs :

// autres imports...
import { babel } from '@rollup/plugin-babel';

export default defineConfig({
  plugins: [
    // autres plugins...
    babel({ babelHelpers: 'runtime', extensions }),
  ],
});

Le plugin babel de @rollup/plugin-babel est l’élément qui prend en compte le fichier de configuration Babel. Les plugins Vite sont basés sur l’interface des plugins Rollup avec quelques options spécifiques à Vite en plus. Par conséquent, les plugins Rollup sont compatibles avec Vite et peuvent être utilisés tels quels dans la config Vite. C’est la raison pour laquelle, si vous écrivez un plugin Vite qui n’utilise que des fonctionnalités héritées de Rollup, la convention est de l’appeler un plugin Rollup.

Structure d’Ember Inspector #

• Ember Inspector est une application Ember qui s’affiche dans une iFrame et récupère des informations de l’application Ember principale affichée sur la page.
• Pour permettre la communication, il injecte un module de débogage sur la page. Ce module est responsable de l’accès et du transfert des données requises vers l’inspecteur.

Cette approche ne fonctionne pas avec Vite, car elle repose sur des modules AMD et des variables globales. Nous devons trouver un nouveau moyen de permettre à l’inspecteur de communiquer avec une application Embroider+Vite. Ce travail comprend plusieurs étapes que nous avons abordées cette semaine  :

• Comprendre comment les informations sont communiquées pour une application Ember classique
• Définir le nouveau protocole pour communiquer les informations depuis une application Embroider+Vite
• Implémenter ce protocole

L’Ember Inspector est un sujet important pour l’Ember Initiative. Ce sera notre principal objectif à partir de la semaine prochaine. L’objectif actuel, avec le budget dont nous disposons, est de rédiger la RFC. Je continuerai également à travailler en parallèle sur quelques issues ouvertes que nous avons sur ember-vite-codemod. Pour que l’Ember Initiative puisse continuer, nous avons besoin de votre soutien 🐹❤️ Contactez Mainmatter.

Intro, Semaine 7, Semaine 9