Embroider と pnpm はどちらも、パッケージが依存関係を正しく宣言することを要求します。依存関係が使用されている場合は、依存関係をリストします (使用されている場合のみ)。

yarn@v1 を使用する大規模なモノリポジトリ (多数の Ember アドオンと Node パッケージを含む Ember アプリを考えてください) で作業する場合、これを行うのは困難です。 Ember アプリは、依存関係が欠落している場合でも、別のパッケージから取り込まれていればビルドして実行できるため、開発者は package.json の更新を忘れる可能性があります。

したがって、ビルドも実行も、一部のパッケージがその依存関係を正しく宣言していないかどうかを知ることはできません。 Embroider と pnpm を導入できるように、package.json を修正するには他にどのようにすればよいでしょうか?

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

import ステートメントから、パッケージが ember-intl と ember-qunit に依存していることがわかります。

そして、テンプレート ファイルが表示される場合は、

{{page-title "My App"}}



{{outlet}}

Ember とそのアドオン エコシステムに関する知識により、それぞれ ember-page-title、ember-welcome-page、ember-source にたどり着きます。暗黙的な場合でも (例: 二重中括弧のあいまいさ、モジュール解決、サービス インジェクション)、Ember の強力な規則のおかげで、アセットの起源を高精度で推測できます。

2. コードモッド

それでも、すべてのパッケージ内のすべてのファイルを手動でチェックするべきではありません。これは時間がかかり、エラーが発生しやすくなります。

代わりに、@codemod-utils を使用して codemod (実際にはリンター) を作成します。すべてのパッケージについて、codemod は関連するものを解析し、存在する必要がある (「実際の」) 依存関係のリストを作成します。次に、そのリストを package.json ("expected").

暗黙的コードを分析するには、考慮したいすべてのパッケージをその資産にマッピングする既知の資産のリスト (1 回限りの作成) が必要です。マップを使用してその情報を記録できます。

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-source と (おそらく) ember-fetch の代わりに、@ember/routing と fetch を依存関係として考慮します。 codemod は、誤検知を簡単にチェックできるような方法で分析を提示する必要があります。

// 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. 結果

私が (数日で) 構築した codemod は、129 個のパッケージを含む運用リポジトリを 49 秒で分析しました。合計 12,377 個のファイルがありましたが、コードモッドが解析できたのはそのうちの 6,013 個だけ (半分未満) でした。これは、ファイルあたり平均 0.008 秒、パッケージあたり 0.38 秒です!

codemod の作成について詳しくは、@codemod-utils のメイン チュートリアルをご覧ください。