Sowohl Embroider als auch pnpm verlangen, dass Pakete ihre Abhängigkeiten korrekt deklarieren: Listen Sie eine Abhängigkeit auf (genau dann), wenn sie verwendet wird.

Dies ist schwierig, wenn Sie an einem großen Monorepo arbeiten (denken Sie an eine Ember-App mit vielen Ember-Add-ons und Node-Paketen), das Yarn@v1 verwendet. Entwickler können vergessen, die package.jsons zu aktualisieren, da die Ember-App auch dann erstellt und ausgeführt werden kann, wenn eine Abhängigkeit fehlt, solange sie aus einem anderen Paket übernommen wird.

Weder Build noch Run können uns also sagen, ob ein Paket seine Abhängigkeiten nicht richtig deklariert hat. Wie können wir sonst die package.jsons reparieren, damit wir Embroider und pnpm einführen können?

1. Statische Code-Analyse

Anhand einer Datei können wir sehen, welche Abhängigkeiten vorhanden sein sollten, da wir wissen, wie JavaScript und Ember funktionieren.

Wäre beispielsweise eine JavaScript- (oder TypeScript-)Datei anzuzeigen,

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');
}

Wir können anhand der Importanweisungen erkennen, dass das Paket von Ember-intl und Ember-qunit abhängt.

Und wenn eine Vorlagendatei angezeigt würde,

{{page-title "My App"}}



{{outlet}}

unser Wissen über Ember und sein Add-on-Ökosystem führt uns jeweils zu Ember-Page-Title, Ember-Welcome-Page und Ember-Source. Selbst wenn Dinge implizit sind (z. B. Mehrdeutigkeit in doppelten geschweiften Klammern, Modulauflösung, Service-Injection), können wir dank der starken Konventionen von Ember den Ursprung eines Assets mit hoher Genauigkeit erraten.

2. Codemod

Dennoch sollten wir nicht jede Datei in jedem Paket manuell überprüfen. Das ist zeitaufwändig und fehleranfällig.

Stattdessen schreiben wir einen Codemod (eigentlich einen Linter) mit @codemod-utils. Für jedes Paket analysiert der Codemod, was relevant ist, und erstellt eine Liste der Abhängigkeiten, die vorhanden sein sollten („tatsächlich“). Anschließend wird die Liste mit der aus package.json („erwartet“) verglichen.

Um impliziten Code zu analysieren, muss eine Liste bekannter Assets vorhanden sein (eine einmalige Erstellung), die jedes Paket, das wir berücksichtigen möchten, seinen Assets zuordnet. Wir können eine Karte verwenden, um diese Informationen aufzuzeichnen.

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'],
    },
  ],
]);

Aufgrund der Funktionsweise von Ember kann eine naive Analyse von Importanweisungen zu falsch positiven Ergebnissen führen. Nehmen Sie das folgende Beispiel:

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

Wenn wir nicht den richtigen Kontext bereitstellen (d. h. dieser Code ist für Ember), würde der Codemod @ember/routing und fetch als Abhängigkeiten betrachten, anstelle von ember-source und (wahrscheinlich) ember-fetch. Der Codemod sollte seine Analyse so präsentieren, dass wir leicht nach Fehlalarmen suchen können.

// 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. Ergebnisse

Der Codemod, den ich (in ein paar Tagen) erstellt hatte, analysierte ein Produktions-Repo mit 129 Paketen in 49 Sekunden. Es gab insgesamt 12.377 Dateien, aber der Codemod konnte nur 6.013 davon analysieren (weniger als die Hälfte). Das sind durchschnittlich 0,008 Sekunden/Datei und 0,38 Sekunden/Paket!

Um mehr über das Schreiben von Codemods zu erfahren, schauen Sie sich das Haupt-Tutorial von @codemod-utils an.