Dependency Hell v projektech — co to je, příčiny a metody řešení

Co je Dependency Hell ve vývoji

Dependency Hell — termín popisující situaci, kdy systém správy závislostí nemůže vyřešit konflikt verzí knihoven. Projekt vyžaduje knihovnu A verzi 1.x a knihovnu B verzi 2.x, ale A závisí na C verzi 1.0 a B na C verzi 2.0, přičemž C:1.0 a C:2.0 jsou nekompatibilní.

Problém je typický pro všechny ekosystémy se správci balíčků. V Androidu — konflikty Gradle mezi support library a AndroidX. V iOS — konflikty CocoaPods mezi různými verzemi Alamofire. V Node.js — konflikty peer dependency v npm. V Pythonu — selhání řešení v pip.

Moderní správci závislostí (npm v7+, Gradle 7+, SwiftPM) vylepšili algoritmy řešení, ale úplné odstranění konfliktů je nemožné při stovkách tranzitivních závislostí. Dependency Hell přešel z kategorie „chyba sestavení" do kategorie „řízení rizik".

Typy konfliktů závislostí v projektech

Diamond dependency — klasika. Knihovna A závisí na D:1.0, knihovna B závisí na D:2.0. Pokud jsou A a B použity společně, správce balíčků musí rozhodnout, kterou verzi D nainstalovat. Ve většině případů je vybrána maximální verze (2.0), ale pokud A není kompatibilní s D:2.0 — konflikt je neřešitelný.

Konflikt verzí — zřejmý nesoulad požadavků. A vyžaduje Logging >=2.0, B vyžaduje Logging <2.0. Správce nemůže splnit obě podmínky. Konflikt peer dependency — plugin A vyžaduje React 17, ale projekt používá React 18 s breaking changes. npm zobrazí varování, ale instalace proběhne — chování se stává nepředvídatelným.

Tranzitivní peklo závislostí — když závislost není přímá, ale nepřímá. Vývojář neví, že knihovna A závisí na B a B na C. Gradle Dependency Tree — nástroj pro vizualizaci celého řetězce závislostí, ukazující, odkud konfliktní knihovna pochází.

Cirkulární závislost — A závisí na B a B závisí na A. Moderní správci (Gradle, npm) blokují cirkulární závislosti ve fázi sestavení. Řešení — vyčlenění společného modulu C, na kterém závisí A i B, přerušení cyklu.

Jak vzniká peklo závislostí

Růst počtu knihoven — hlavní předpoklad. Každý modul přidává přímé a tranzitivní závislosti. V Android projektu s Jetpack Compose, Firebase, Retrofit a Coil počet tranzitivních závislostí snadno přesahuje 500. Každá nová knihovna je potenciální konflikt.

Nesynchronizované aktualizace — týmy aktualizují knihovny v různých časech. Backend tým aktualizuje Jackson na 2.15, analytický tým používá 2.12. Při integraci modulů vzniká konflikt. Řešení — centralizované verze (Bill of Materials) v BOM souboru Gradle nebo katalogu verzí.

Různé verze stejné knihovny — klasická situace: modul A používá OkHttp 3.12, modul B — OkHttp 4.0. Pokud aktualizace na 4.0 rozbije modul A, projekt uvízne na dvou verzích, což může vést ke konfliktům classpath v Javě nebo duplicitním symbolům v iOS.

Diagnostika problému v projektu

Gradle Dependency Tree — příkaz `gradle dependencies` zobrazí úplný strom závislostí s označením konfliktů. Resolved version ukazuje, kterou verzi Gradle vybral, a konfliktní verze jsou označeny šipkami. Příklad: `com.squareup.okhttp3:okhttp -> 4.9.3 (*)` — verze vyřešena, (*) — duplikace.

npm ls — analogický příkaz pro Node.js. Přepínač `--all` zobrazí úplný strom. Konflikty peer dependency jsou zobrazeny s varováními. SwiftPM Graph — `swift package show-dependencies` zobrazí graf závislostí pro iOS projekty, včetně větví a revizí.

Dependency Analysis Plugin — Gradle plugin od Autonomy, který nachází nepoužité závislosti a konflikty. Ben Manes Versions Plugin — kontroluje, které závislosti jsou zastaralé, a zobrazuje dostupné aktualizace. Oba nástroje automatizují rutinní kontrolu kompatibility.

Příklad: analýza konfliktu v Gradle

// Konflikt: modul A potřebuje okhttp 3.x, modul B potřebuje okhttp 4.x
dependencies {
    implementation("com.example:module-a:1.0")  // → okhttp 3.12
    implementation("com.example:module-b:2.0")  // → okhttp 4.0
}

// Řešení: vynuťte konkrétní verzi
configurations.all {
    resolutionStrategy {
        force "com.squareup.okhttp3:okhttp:4.9.3"
    }
}

Nástroje pro řešení konfliktů

Version Catalog (Gradle 7+) — centralizované deklarování verzí v TOML souboru. Všechny moduly používají stejné verze knihoven. Příklad: soubor `libs.versions.toml` obsahuje `okhttp = "4.9.3"` a všechny moduly odkazují na tento katalog. Konflikt verzí mezi moduly je vyloučen.

Bill of Materials (Spring BOM) — koncept Maven, ve kterém jsou stanoveny kompatibilní verze knihoven. Android tým Googlu používá Compose BOM pro knihovny Jetpack. Připojením BOM získáte záruku, že všechny verze Compose jsou vzájemně kompatibilní.

Renovate a Dependabot — autoři automatických PR pro aktualizaci závislostí. Renovate seskupuje kompatibilní aktualizace, kontroluje breaking changes pomocí Docker obrazů. Dependabot — vestavěné řešení GitHub, které aktualizuje závislosti a kontroluje kompatibilitu přes CI.

Strategie prevence pekla závislostí

Semantic Versioning — používejte caret `^1.2.3` pro patch/minor aktualizace a tilde `~1.2.3` pouze pro patch. Ale ani semver nezaručuje kompatibilitu — skutečná porušení semver se vyskytují v 15 % případů (podle výzkumu University of Luxembourg, 2024). Lock soubory fixují přesnou verzi, která prošla testy.

Minimalizace závislostí — každá knihovna musí být odůvodněna. Pokud můžete funkcionalitu implementovat ve 20 řádcích vlastního kódu — nepřidávejte knihovnu. Příklad: místo knihovny pro formátování dat (4 tranzitivní závislosti) použijte vestavěné nástroje platformy. Pravidlo „rozpočtu závislostí" — ne více než 50 přímých závislostí na projekt.

Pravidelné aktualizace — aktualizujte závislosti v malých krocích, ne jednou ročně. Dependabot vytváří PR pro každou aktualizaci. CI by mělo spouštět kompletní sadu testů. DevContainer — jednotné vývojové prostředí, ve kterém verze závislostí odpovídají produkci, čímž se eliminují konflikty mezi prostředími.