Direct dependency — loyiha kodi yoki build konfiguratsiyasi bevosita nomlab, ishlatadigan tashqi paket, modul, kutubxona yoki komponentdir. Masalan, dastur HTTP so‘rov yuborish uchun muayyan kutubxonaning APIini import qilsa, shu kutubxona uning to‘g‘ridan-to‘g‘ri bog‘liqligi hisoblanadi. Direct dependency ham boshqa paketlarga tayanishi mumkin; ular loyiha uchun transitive dependency bo‘ladi.
Manifestdagi ifoda
Package managerlar direct dependencylarni manifest faylida saqlaydi. Manifest odatda paket nomi, ruxsat etilgan versiya oralig‘i va foydalanish guruhini ko‘rsatadi. Lock file esa resolver tanlagan aniq versiyalar va ko‘pincha integrity hashlarini qayd etadi. Manifest niyatni, lock file takrorlanadigan o‘rnatish natijasini ifodalaydi.
Runtime dependency mahsulot ishlaganda kerak bo‘ladi. Development dependency test, lint, hujjat yoki build uchun ishlatiladi, lekin yakuniy runtime imagega kirmasligi mumkin. Optional va peer dependency kabi toifalarning ma’nosi package managerga xos. Noto‘g‘ri tasnif productionda modul topilmasligi yoki artefaktning keraksiz kattalashishiga olib keladi.
Versiya tanlash
Versiya diapazoni loyiha qaysi yangilanishlarni avtomatik qabul qilishini belgilaydi. Juda keng diapazon yangi release bilan kutilmagan xatti-harakat keltirishi mumkin; aniq versiyani har joyda qo‘lda mahkamlash esa xavfsizlik tuzatishlarini sekinlashtiradi. Amaliy model manifestda moslik oralig‘ini, lock fileda aniq yechimni saqlab, yangilanishni avtomatik test orqali nazorat qilishdir.
Bir xil paketni loyihaning ikki direct dependency qismi turli diapazonda talab qilishi mumkin. Resolver bitta mos versiyani tanlashi, bir nechta nusxani o‘rnatishi yoki konflikt bilan to‘xtashi mumkin. Natija tilning module resolution qoidalari va paket formatiga bog‘liq. Shu sababli dependency graph faqat tekis ro‘yxat emas.
API va arxitektura
Direct dependency APIlari loyiha kodida ko‘rinadi va almashtirish xarajatini oshiradi. Adapter qatlam keng kutubxonaning faqat zarur qismini ichki interfeys ortiga yashirishi mumkin. Biroq har kichik paket uchun abstraksiya yaratish ham ortiqcha murakkablik tug‘diradi. Chegara kutubxonaning barqarorligi, biznes kodiga tarqalishi va muqobil implementatsiya ehtimoliga qarab tanlanadi.
Dependency inversionda yuqori darajadagi modul konkret tashqi paketga emas, ichki abstraksiyaga bog‘lanadi. Tashqi adapter shu abstraksiyani amalga oshiradi. Bu test double yaratish va vendorni almashtirishni yengillashtiradi, ammo tashqi semantikani to‘liq yashirish har doim mumkin emas.
Ta’minot zanjiri xavfi
Har direct dependency loyihaga kod, maintainer qarorlari va uning transitive grafini olib kiradi. Paket tanlashda faol xizmat ko‘rsatish, litsenziya, release tarixi, vulnerability holati, imzolash va reproducible build imkoniyati ko‘riladi. Faqat yuklab olish soni xavfsizlik kafolati emas.
Dependency minimal huquq bilan bajariladi. Build script, compiler plugin va package install hooklari build mashinasida kod bajarishi mumkin, shuning uchun development dependency ham ta’minot zanjiri xavfiga ega. CI tarmoq ruxsati, secretlar va filesystem chegarasi bilan izolyatsiya qilinadi.
Inventar va yangilash
SBOM direct va transitive komponentlarni versiya va kelib chiqishi bilan inventarizatsiya qiladi. Avtomatik bot yangi versiya uchun alohida o‘zgarish yaratishi mumkin; unit, integratsion va compatibility testlar qarorni qo‘llab-quvvatlaydi. Ishlatilmay qolgan direct dependency manifestdan va koddan chiqariladi. Bu build vaqtini, attack surface va litsenziya majburiyatlarini kamaytiradi.
Dependency egasi tashkilot ichida ham belgilanadi. Yangilanish, advisory va major migratsiya uchun javobgar jamoa bo‘lmasa, muhim paket versiyasi qarovsiz qoladi.
Bog‘liq tushunchalar
Transitive dependency, Package manager, Dependency graph, Lock file, Semantic Versioning, Software supply chain, SBOM