Transitive dependency — loyiha bevosita tanlamagan, ammo uning direct dependencylaridan biri talab qilgani sababli dependency graphga kiradigan paket yoki moduldir. Agar A loyihasi B kutubxonasidan, B esa C paketidan foydalansa, C A uchun transitive dependency hisoblanadi. Dastur C APIini import qilmasligi mumkin, lekin Cning kodi, versiyasi va zaifliklari baribir build yoki runtime natijasiga ta’sir qiladi.
Resolver vazifasi
Package manager manifestlardan dependency talablarini yig‘ib, o‘zaro mos versiyalarni topadi. Graphda bir paket bir necha yo‘l orqali kelishi mumkin. Resolver versiyalarni deduplicate qilishi, har parent ostiga alohida nusxa joylashi yoki mos diapazon topilmasa xato berishi mumkin. Bu xatti-harakat ekotizim va module loader qoidalariga bog‘liq.
Lock file tanlangan transitive versiyalarni ham qayd etadi. Shu sababli faqat top-level manifest o‘zgarmagan bo‘lsa ham lock filesiz ikki o‘rnatish turli graph hosil qilishi mumkin. Integrity hash paket kontenti kutilmaganda almashtirilmaganini tekshiradi, ammo kodning xavfsiz ekanini isbotlamaydi.
Yashirin bog‘lanish
Ba’zan loyiha C paketini manifestda ko‘rsatmasdan import qiladi, chunki u B bilan birga tasodifan o‘rnatilgan. Bu undeclared dependencydir. B keyingi versiyada Cni olib tashlasa yoki boshqa joyga ko‘chirsa, A buziladi. Loyiha foydalanadigan har API egasi direct dependency sifatida deklaratsiya qilinishi kerak.
Transitive paket public API tiplarida ko‘rinishi ham mumkin. B kutubxonasi Cga tegishli obyektni o‘z interfeysidan qaytarsa, iste’molchi C versiyasiga bilvosita bog‘lanadi. Bning maintainerri C tiplarini ichki adapter ortida yashirish yoki Cni aniq peer dependency sifatida e’lon qilish orqali bu chegarani boshqaradi.
Xavfsizlik va litsenziya
Kichik direct dependency yuzlab transitive paket olib kelishi mumkin. Ularning har biri komprometatsiya, malicious maintainer, typosquatting yoki e’lon qilingan vulnerability manbai bo‘la oladi. Vulnerability scanner graphdagi paketning haqiqatan deploy artefaktga kirganini, zaif funksiya reachable ekanini va tuzatilgan versiyaga qaysi parent to‘sqinlik qilayotganini ko‘rsatishi kerak.
Litsenziya majburiyati ham faqat direct ro‘yxat bilan cheklanmaydi. Tarqatiladigan binary yoki containerga kirgan barcha komponentlarning litsenziyasi tekshiriladi. SBOM dependency yo‘li bilan birga paket nomi, versiya, hash va manbani qayd etsa, hodisaga javob berish tezlashadi.
Yangilash usullari
Transitive paketdagi xato odatda uni talab qiluvchi direct dependency yangilanishi orqali tuzatiladi. Package manager override yoki resolution qoidasiga ruxsat bersa, vaqtincha yuqoriroq xavfsiz versiya majburan tanlanishi mumkin. Bunday override API mosligini kafolatlamaydi; test va olib tashlash muddati bilan kuzatiladi.
Dependency graphni muntazam yangilash katta sakrashlarni kamaytiradi. Avtomatik PRlar kichik versiya o‘zgarishini test qiladi, lekin generated lock file reviewdan o‘tadi. Bir paketning yangilanishi kutilmagan o‘nlab transitive o‘zgarishni keltirsa, changelog va graph diff alohida tekshiriladi.
Grafni qisqartirish
Ishlatilmaydigan direct dependencyni olib tashlash uning butun pastki grafini chiqarishi mumkin. Production artefaktga faqat runtime dependencylarni kiritish build vositalari va test paketlarini tashqarida qoldiradi. Biroq tree shaking faqat bajarilmaydigan kodni olib tashlaydi; paket inventari va litsenziya tahlili uchun source graph ham saqlanadi. Vendor qilish graphni yo‘q qilmaydi, faqat komponent kodini repository ichiga ko‘chiradi.
Bog‘liq tushunchalar
Direct dependency, Dependency graph, Package manager, Lock file, Version constraint, Software supply chain, SBOM