एम्ब्रॉयडर और पीएनपीएम दोनों पूछते हैं कि पैकेज अपनी निर्भरता को सही ढंग से घोषित करते हैं: एक निर्भरता को सूचीबद्ध करें (यदि और केवल) यदि इसका उपयोग किया जाता है।

बड़े मोनोरेपो (कई एम्बर ऐडऑन और नोड पैकेज के साथ एक एम्बर ऐप पर विचार करें) पर काम करते समय ऐसा करना मुश्किल है जो यार्न@वी1 का उपयोग करता है। डेवलपर्स package.json को अपडेट करना भूल सकते हैं, क्योंकि एम्बर ऐप एक निर्भरता गायब होने पर भी बना और चला सकता है, जब तक कि इसे दूसरे पैकेज से खींच लिया जाता है।

इसलिए न तो बिल्ड और न ही रन हमें बता सकते हैं कि क्या किसी पैकेज ने अपनी निर्भरता को सही घोषित नहीं किया है। हम package.json को और कैसे ठीक कर सकते हैं ताकि हम Embroider और pnpm पेश कर सकें?

1. स्थैतिक कोड विश्लेषण

एक फ़ाइल देते हुए, हम देख सकते हैं कि कौन सी निर्भरताएँ मौजूद होनी चाहिए, क्योंकि हम जानते हैं कि जावास्क्रिप्ट और एम्बर कैसे काम करते हैं।

उदाहरण के लिए, दिखाने के लिए एक जावास्क्रिप्ट (या टाइपस्क्रिप्ट) फ़ाइल थी,

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

हम आयात विवरण से बता सकते हैं कि पैकेज एम्बर-इंटल और एम्बर-क्यूनिट पर निर्भर करता है।

और, यदि कोई टेम्प्लेट फ़ाइल दिखानी हो,

{{page-title "My App"}}



{{outlet}}

एंबर और उसके ऐडऑन इकोसिस्टम के बारे में हमारा ज्ञान हमें क्रमशः एम्बर-पेज-शीर्षक, एम्बर-स्वागत-पेज और एम्बर-स्रोत तक ले जाता है। यहां तक ​​​​कि जब चीजें अंतर्निहित होती हैं (उदाहरण के लिए डबल घुंघराले ब्रेसिज़, मॉड्यूल रिज़ॉल्यूशन, सेवा इंजेक्शन में अस्पष्टता), हम एम्बर के मजबूत सम्मेलनों के लिए उच्च सटीकता के साथ संपत्ति की उत्पत्ति का अनुमान लगा सकते हैं।

2. कोडमॉड

फिर भी, हमें प्रत्येक पैकेज की प्रत्येक फ़ाइल को मैन्युअल रूप से जांचना नहीं चाहिए। यह समय लेने वाला और त्रुटि-प्रवण है।

इसके बजाय, हम @codemod-utils का उपयोग करके एक कोडमॉड (वास्तव में, एक लिंटर) लिखते हैं। प्रत्येक पैकेज के लिए, कोडमॉड जो प्रासंगिक है उसे पार्स करता है और निर्भरताओं की एक सूची बनाता है जो मौजूद होनी चाहिए ("वास्तविक")। इसके बाद यह सूची की तुलना 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'],
    },
  ],
]);

अब, एम्बर कैसे काम करता है, इसके कारण आयात विवरणों का एक सरल विश्लेषण गलत सकारात्मक परिणाम दे सकता है। निम्नलिखित उदाहरण लें:

import Route from '@ember/routing/route';
import fetch from '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। परिणाम

मैंने जो कोडमॉड बनाया था (कुछ दिनों में) उसने 49 सेकंड में 129 पैकेजों के साथ एक उत्पादन रेपो का विश्लेषण किया। कुल 12,377 फ़ाइलें थीं, लेकिन कोडमॉड उनमें से केवल 6,013 (आधे से भी कम) का विश्लेषण करना जानता था। यह औसतन 0.008 सेकंड/फ़ाइल और 0.38 सेकंड/पैकेज है!

कोडमोड लिखने के बारे में अधिक जानने के लिए, @codemod-utils से मुख्य ट्यूटोरियल देखें।