Embroider et pnpm demandent tous deux que les packages déclarent correctement leurs dépendances : répertoriez une dépendance (si et seulement) si elle est utilisée.

Cela est difficile à faire lorsque vous travaillez sur un grand monorepo (pensez à une application Ember avec de nombreux modules complémentaires Ember et packages Node) qui utilise fil@v1. Les développeurs peuvent oublier de mettre à jour le package.json, car l'application Ember peut être créée et exécutée même lorsqu'une dépendance est manquante, à condition qu'elle soit extraite d'un autre package.

Ainsi, ni build ni run ne peuvent nous dire si un package n'a pas déclaré correctement ses dépendances. Sinon, comment pouvons-nous corriger les package.json afin de pouvoir introduire Embroider et pnpm ?

1. Analyse du code statique

Étant donné un fichier, nous pouvons voir quelles dépendances doivent être présentes, car nous savons comment fonctionnent JavaScript et Ember.

Par exemple, si un fichier JavaScript (ou TypeScript) devait être affiché,

import { setupIntl } from 'ember-intl/test-support';
import { setupRenderingTest as upstreamSetupRenderingTest } from 'ember-qunit';

export function setupRenderingTest(hooks, options) {
  upstreamSetupRenderingTest(hooks, options);

  // Additional setup for rendering tests can be done here.
  setupIntl(hooks, 'de-de');
}

nous pouvons déduire des instructions d'importation que le package dépend de ember-intl et ember-qunit.

Et, si un fichier modèle devait s'afficher,

{{page-title "My App"}}



{{outlet}}

notre connaissance d'Ember et de son écosystème de modules complémentaires nous oriente respectivement vers le titre de la page de braise, la page de bienvenue de braise et la source de braise. Même lorsque les choses sont implicites (par exemple, ambiguïté dans les doubles accolades, résolution de module, injection de service), nous pouvons deviner l'origine d'un actif avec une grande précision, grâce aux conventions fortes d'Ember.

2. Codemod

Pourtant, nous ne devrions pas vérifier manuellement chaque fichier de chaque package. Cela prend du temps et est sujet aux erreurs.

Au lieu de cela, nous écrivons un codemod (en fait, un linter) en utilisant @codemod-utils. Pour chaque package, le codemod analyse ce qui est pertinent et crée une liste de dépendances qui doivent être présentes (« réelles »). Il compare ensuite la liste à celle de package.json ("attendu").

Pour analyser le code implicite, il doit exister une liste d'actifs connus (une création unique), qui mappe chaque package que nous souhaitons prendre en compte à ses actifs. Nous pouvons utiliser une carte pour enregistrer ces informations.

const KNOWN_ASSETS = new Map([
  [
    'ember-intl',
    {
      helpers: [
        'format-date',
        'format-list',
        'format-message',
        'format-number',
        'format-relative',
        'format-time',
        't',
      ],
      services: ['intl'],
    },
  ],
  [
    'ember-page-title',
    {
      helpers: ['page-title'],
      services: ['page-title'],
    },
  ],
  [
    'ember-welcome-page',
    {
      components: ['welcome-page'],
    },
  ],
]);

Maintenant, en raison du fonctionnement d'Ember, une analyse naïve des déclarations d'importation peut conduire à des faux positifs. Prenons l'exemple suivant :

import Route from '@ember/routing/route';
import fetch from 'fetch';

Lorsque nous ne fournissons pas le bon contexte (c'est-à-dire que ce code est pour Ember), le codemod considérerait @ember/routing et fetch comme des dépendances, au lieu de ember-source et (probablement) ember-fetch. Le codemod doit présenter son analyse de manière à ce que nous puissions facilement vérifier les faux positifs.

// Results for my-package-37

{
  missingDependencies: [
    'ember-asset-loader',
    'ember-truth-helpers'
  ],
  unusedDependencies: [
    '@babel/core',
    'ember-auto-import',
    'ember-cli-babel'
  ],
  unknowns: [
    'Services - host-router (addon/routes/registration.ts)',
  ]
}

3. Résultats

Le codemod que j'avais construit (en quelques jours) a analysé un dépôt de production avec 129 packages en 49 secondes. Il y avait un total de 12 377 fichiers, mais le codemod n'a su en analyser que 6 013 (moins de la moitié). Cela représente une moyenne de 0,008 seconde/fichier et de 0,38 seconde/package !

Pour en savoir plus sur l'écriture de codemods, consultez le didacticiel principal de @codemod-utils.