Embroider와 pnpm은 모두 패키지가 종속성을 올바르게 선언하도록 요청합니다. 종속성이 사용되는 경우에만 종속성을 나열합니다.

yarn@v1을 사용하는 대규모 단일 저장소(많은 Ember 애드온 및 노드 패키지가 포함된 Ember 앱 고려)에서 작업할 때 이는 수행하기 어렵습니다. 개발자는 package.json 업데이트를 잊어버릴 수 있습니다. Ember 앱은 종속성이 누락된 경우에도 다른 패키지에서 가져오기만 하면 빌드하고 실행할 수 있기 때문입니다.

따라서 빌드나 실행 중 어느 것도 일부 패키지가 종속성을 올바르게 선언하지 않았는지 알 수 없습니다. 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(실제로는 linter)를 작성합니다. 모든 패키지에 대해 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-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는 (이틀 만에) 49초 만에 129개의 패키지가 포함된 프로덕션 저장소를 분석했습니다. 총 12,377개의 파일이 있었지만 codemod는 그 중 6,013개(절반 미만)만 분석할 수 있다는 것을 알고 있었습니다. 이는 평균 0.008초/파일, 0.38초/패키지입니다!

codemod 작성에 대해 자세히 알아보려면 @codemod-utils의 기본 튜토리얼을 확인하세요.