Correction des dépendances des packages

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

C'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 les 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

À partir d'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 déclarations 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"}}

<WelcomePage />

{{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 fortes conventions 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 y avoir une liste d'actifs connus (une création unique), qui mappe chaque package que nous voulons considérer à 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 à de 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 0,38 seconde/package !

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!