И Embroider, и pnpm требуют, чтобы пакеты правильно объявляли свои зависимости: укажите зависимость (если и только), если она используется.

Это сложно сделать при работе с большим монорепозиторием (представим себе приложение Ember со множеством надстроек Ember и пакетами Node), использующим Yarn@v1. Разработчики могут забыть обновить package.json, потому что приложение Ember может создаваться и запускаться даже при отсутствии зависимости, если оно извлекается из другого пакета.

Поэтому ни сборка, ни запуск не могут сказать нам, если какой-то пакет неправильно объявил свои зависимости. Как еще мы можем исправить package.json, чтобы можно было использовать Embroider и pnpm?

1. Статический анализ кода

По файлу мы можем увидеть, какие зависимости должны присутствовать, потому что мы знаем, как работают JavaScript и Ember.

Например, если бы отображался файл JavaScript (или TypeScript),

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

из операторов импорта мы можем сказать, что пакет зависит от ember-intl и ember-qunit.

И если бы отображался файл шаблона,

{{page-title "My App"}}



{{outlet}}

наши знания об Ember и его экосистеме дополнений направляют нас к ember-page-title, ember-welcome-page и ember-source соответственно. Даже когда вещи неявны (например, двусмысленность в двойных фигурных скобках, разрешение модулей, внедрение сервисов), мы можем угадать происхождение актива с высокой точностью благодаря строгим соглашениям Ember.

2. Кодмод

Тем не менее, нам не следует вручную проверять каждый файл в каждом пакете. Это отнимает много времени и чревато ошибками.

Вместо этого мы пишем кодмод (на самом деле линтер), используя @codemod-utils. Для каждого пакета codemod анализирует то, что актуально, и создает список зависимостей, которые должны присутствовать («фактические»). Затем он сравнивает список со списком из package.json («ожидаемый»).

Для анализа неявного кода необходим список известных ресурсов (одноразовый), который сопоставляет каждый пакет, который мы хотим рассмотреть, с его активами. Мы можем использовать карту для записи этой информации.

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

Теперь, из-за особенностей работы Ember, наивный анализ операторов импорта может привести к ложным срабатываниям. Возьмем следующий пример:

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

Когда мы не предоставляем правильный контекст (т. е. этот код предназначен для Ember), codemod будет рассматривать @ember/routing и fetch как зависимости вместо ember-source и (вероятно) ember-fetch. Кодмод должен представить свой анализ таким образом, чтобы мы могли легко проверить ложные срабатывания.

// 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. Результаты

Кодмод, который я создал (за пару дней), проанализировал производственный репозиторий со 129 пакетами за 49 секунд. Всего было 12 377 файлов, но кодмод смог проанализировать только 6013 из них (меньше половины). Это в среднем 0,008 секунды на файл и 0,38 секунды на пакет!

Чтобы узнать больше о написании кодовых модов, ознакомьтесь с основным руководством от @codemod-utils.