>  기사  >  웹 프론트엔드  >  패키지 종속성 수정

패키지 종속성 수정

WBOY
WBOY원래의
2024-07-19 19:43:32297검색

Fixing Package Dependencies

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

yarn@v1을 사용하는 대규모 모노레포(Ember 애드온 및 노드 패키지가 많은 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"}}

<WelcomePage />

{{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 문을 단순하게 분석하면 오탐지로 이어질 수 있습니다. 다음 예를 들어보세요:

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의 기본 튜토리얼을 확인하세요.

위 내용은 패키지 종속성 수정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
이전 기사:JS의 WeakSet?다음 기사:JS의 WeakSet?