Ersätt NuGet med NoGet

Priset vi betalar för "Install-Package"

Att bygga mjukvara idag handlar till stor del om att stå på jättars axlar. NuGet har revolutionerat vårt sätt att arbeta med .NET, men det finns en baksida med att ha ett alltför välfyllt PackageReferences-arkiv. Varje externt beroende vi lägger till är i praktiken ett lån från framtiden, där räntan betalas i form av ökad komplexitet och risk.

Från beroendekonflikter till säkerhetshål

Ett av de mest påtagliga problemen är det vi brukar kalla för "Dependency Hell". Det börjar ofta oskyldigt med att två olika paket kräver samma underliggande bibliotek, men i olika versioner. Plötsligt sitter du med märkliga kompileringsfel eller, ännu värre, runtime-krascher som är extremt svåra att felsöka. Men huvudvärken slutar inte vid tekniska konflikter; den sträcker sig hela vägen till säkerhetsavdelningen. Genom att ta in dussintals paket öppnar du dörren för så kallade Supply Chain Attacks. Du litar inte bara på utvecklaren av paketet du installerade, utan även på alla utvecklare av de paket som de i sin tur har valt att använda. Din applikations attackyta växer exponentiellt för varje rad i din projektfil.

När ramverket springer ifrån paketen

Vi ser också ofta hur förkärleken till externa paket blir ett ankare vid uppgraderingar. När en ny version av .NET släpps vill vi kunna dra nytta av de senaste prestandaförbättringarna direkt. Men om din lösning vilar på ett fundament av tjugo olika community-projekt, blir du låst av den långsammaste länken. Om ett enda kritiskt paket inte har hunnit uppdateras för att stödja den nya miljön, sitter hela din kodbas fast i den gamla versionen.

Bloat och "Left-pad"-syndromet

Det finns också en tendens att vi blir lata. Istället för att skriva tio rader logik för att hantera en enkel strängmanipulation eller ett specifikt datumformat, installerar vi ett helt bibliotek. Detta leder till en onödig "bloat" där binärfilerna växer och starttiderna förlängs. Det skapar dessutom en skörhet som påminner om det ökända "Left-pad"-fallet i JavaScript-världen; om en utvecklare väljer att dra tillbaka ett litet paket som "alla" använder, stannar hela byggkedjan upp.

Licenser och arkitektoniskt läckage

Slutligen får vi inte glömma de juridiska och arkitektoniska aspekterna. Att hålla koll på licensvillkor för hundratals transitiva beroenden är en administrativ mardröm som kan få rättsliga efterspel. Rent tekniskt riskerar vi även "Leaky Abstractions", där ett specifikt pakets logik smyger sig in i vår egen affärslogik. Den dagen paketet slutar underhållas eller dess prestanda inte längre räcker till, inser vi att vi inte bara har använt ett verktyg – vi har byggt in oss i ett hörn som kräver en total refactoring att ta sig ur.

Att vara restriktiv med NuGet-paket handlar inte om att uppfinna hjulet på nytt, utan om att välja sina strider och behålla kontrollen över sin egen källkod.