يطلب كل من Embroider و pnpm أن تعلن الحزم عن تبعياتها بشكل صحيح: قم بإدراج التبعية (إذا وفقط) إذا تم استخدامها.

يصعب القيام بذلك عند العمل على monorepo كبير (فكر في تطبيق Ember الذي يحتوي على العديد من إضافات Ember وحزم Node) الذي يستخدم Yarn@v1. يمكن للمطورين أن ينسوا تحديث الحزمة.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، وصفحة ترحيب Ember، ومصدر Ember، على التوالي. حتى عندما تكون الأمور ضمنية (على سبيل المثال، الغموض في الأقواس المزدوجة المتعرجة، دقة الوحدة، حقن الخدمة)، يمكننا تخمين أصل الأصل بدقة عالية، وذلك بفضل اصطلاحات Ember القوية.

2. كود مود

ومع ذلك، لا ينبغي لنا التحقق من كل ملف في كل حزمة يدويًا. وهذا يستغرق وقتًا طويلاً وعرضة للأخطاء.

بدلاً من ذلك، نكتب codemod (في الواقع، linter) باستخدام @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)، فإن الكودود سيعتبر @ember/routing وfetch بمثابة تبعيات، بدلاً من ember-source و(المحتمل) ember-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 ثانية. كان هناك إجمالي 12377 ملفًا، لكن برنامج codemod كان قادرًا على تحليل 6013 منها فقط (أقل من النصف). هذا يعني في المتوسط ​​0.008 ثانية/ملف و0.38 ثانية/حزمة!

لمعرفة المزيد حول كتابة تعديلات الكود، راجع البرنامج التعليمي الرئيسي من @codemod-utils.