Development Dependency — dastur ishlab chiqish, testlash, lint, formatlash yoki build qilish uchun kerak, ammo odatda production runtime’da bevosita talab qilinmaydigan paket. Uning toifasi deployment tarkibi va attack surface’ga ta’sir qiladi.
Tipik vositalar
Test framework, linter, type checker, bundler plugin va documentation generator tipik misollardir. Paket manifestida alohida dev bo‘limi yoki scope bilan belgilanadi. CI build bosqichi ularni o‘rnatishi mumkin, minimal runtime image esa olib tashlaydi.
Build va deploy
Build-time tool generated code yoki bundle yaratib bersa, production containerda toolning o‘zi kerak emas, natija kerak. Multi-stage container birinchi bosqichda dev dependencylar bilan build qiladi, ikkinchisiga faqat artefakt va runtime dependencylarni ko‘chiradi.
Xavfsizlik
Dev dependency xavfsiz emas deb e’tiborsiz qoldirilmaydi: u CI’da token, source code va release artefaktiga kirishi mumkin. Malicious build plugin production binaryga kod kiritishi mumkin. Audit va pinning ikkala toifa uchun qo‘llanadi.
Scope qoidalari
Ba’zi package manager peer, optional va dev transitive qoidalarini turlicha talqin qiladi. Package library sifatida tarqatilsa, consumerga kerak build-time type declaration yoki plugin noto‘g‘ri dev scope’da qolmasligi kerak.
Minimal production
Productionda dev dependency o‘rnatmaslik image hajmi va vulnerability sonini kamaytiradi, lekin build output runtime’da yashirin require qilsa startup xatosi beradi. Clean production install smoke test buni topadi.
Sinov
Tekshiruv manifest scope, lockfile va final image package ro‘yxatini solishtiradi. Testlar dev paketlarsiz tayyor artefaktning ishlashini, toza checkoutda esa dev toolchain qayta build qila olishini tekshiradi.
Development dependencylar final SBOMda build-time scope bilan alohida ko‘rsatiladi. Ular runtime image’da yo‘q bo‘lsa ham release provenance qaysi tool artefaktni yaratganini qayd etadi.
+## Amaliy boshqaruv
Development Dependency production pipeline’da deterministik bo‘lishi kerak. Bir xil input, target va optionlar bir xil muhim metadata hamda qarorni hosil qiladi. compiler plugin, linter va generated artefakt tartibi hash yoki outputga tasodifiy ta’sir qilsa cache va regressiya tahlili ishonchsiz bo‘ladi. Shu sabab traversal tartibi, identifier va serialized yozuvlar barqarorlashtiriladi; vaqt, mutlaq path yoki processga xos qiymatlar remap qilinadi.
Muhim xato sinfi — CI tokeniga ega zararli build paketi. Bunday holatda vosita optimistik taxmin bilan davom etmaydi: zarur bo‘lsa sekinroq, lekin xavfsiz yo‘l tanlanadi yoki aniq diagnostika bilan jarayon to‘xtatiladi. Xatoni qayta ishlab bo‘ladigan qilish uchun target, optionlar, kirish identifikatori va tegishli metadata qayd etiladi. Foydalanuvchi ma’lumoti xom shaklda loglanmaydi; hash, build-id yoki cheklangan kontekst yetarli bo‘lgan joyda shular ishlatiladi.
Sifat nazorati devsiz runtime image va toza checkout build testi orqali bajariladi. Testlar normal misol bilan cheklanmay, bo‘sh kirish, minimal va maksimal o‘lcham, mos kelmaydigan versiya, yo‘qolgan komponent hamda parallel holatlarni qamraydi. Natijaning to‘g‘riligi performance o‘lchovidan alohida baholanadi. Keyin vaqt, xotira, artefakt hajmi yoki runtime kechikishi kabi mavzuga mos metrikalar baseline bilan solishtiriladi. Regressiya topilsa, minimal takrorlanuvchi holat saqlanib, keyingi release uchun doimiy testga aylantiriladi.
Bog‘liq tushunchalar
runtime dependency, build dependency, package manifest, CI pipeline, multi-stage build, dependency audit