Beroendeförvaltning kan vara knölig. När jag började arbeta på dojo4 för några veckor sedan, var det fantastiskt att klona en ruby on rails-projektrepo, kunna köra bundle install och sedan kunna köra appen med rails s. För dem av er som inte är bekanta med ruby on rails beroendeförvaltning, listade de gems som behövs för att köra applikationen i en fil som heter Gemfile. Bundle-applikationen läser den här gemfilen och laddar ner och installerar alla gems som inte finns på din dator ännu. Detta gör det inte bara enkelt att få applikationen att fungera korrekt snabbt och utan mycket installationsarbete, det gör också att det blir enkelt att uppdatera dessa beroenden när en ny version släpps. Att köra bundle update eller uppdatera gemfilen och köra bundle install igen gör det till en enkel process som garanterar att alla andra användare av appen också kommer att använda den nya versionen (förutsatt att vi delar ändringarna via källkodkontroll). Detta är ett fantastiskt arbetsflöde för serversidan, men vad gäller klientsidan?

När klientapplikationer blir mer komplicerade behöver vi ofta hjälp av bibliotek och ramverk på klientsidan också. På dojo4 laddar vi för närvarande ner de filer vi behöver och lägger manuellt till de nödvändiga filerna i källkodkontrollen och commit:ar dem. Filerna är under källkodkontroll, så åtminstone kommer alla att få dessa filer och vi kan återställa en versionsuppgradering, men det är lite oredigt. För att uppdatera biblioteksfilerna måste vi upprepa den manuella processen. På serversidan är det också väldigt användbart att beroendeförvaltningsuppgifter är mindre starkt kopplade till applikationskoden så att uppdateringar och återställningar av versioner blir enklare. Tyvärr har det inte funnits ett bra sätt att hantera beroenden för frontenden. Tills nyligen.

I september förra året släppte Twitter Bower, som erbjuder ”en generisk, oopinionerad lösning på problemet med front-end pakethantering”. Bower ger samma möjligheter för front-end applikationen som bundle gör för back-end: en central lista över beroenden i en fil, enkla installations- och uppdateringskommandon, och en viss separation från appkoden och commits. När jag undersökte hur vi kunde dra nytta av detta i vår standard ruby on rails-applikation, hänvisades jag av Bower-skaparna till bower-rails gem, som integrerar bower i ruby on rails-katalogstrukturen och lägger till några rake kommandon för att köra bower-kommandon. Nu behöver en utvecklare inte längre committa biblioteksfiler till apprepon manuellt, en utvecklare kan köra rake bower:install [paketnamn] och den senaste versionen av det paketet kommer att installeras i asset-pipelinen och kommer att läggas till i listan över krävda paket. En ny utvecklare kan sedan ladda ner appkoden och efter att ha kört bundle install, köra rake bower:install och alla front-end beroenden kommer att installeras i den korrekta katalogen i ruby on rails asset-pipelinen för omedelbar användning.

Personligen tycker jag mycket om den här metoden och hoppas att vi kan konvertera de front-end bibliotek som läggs till manuellt till bower-metoden. Vi diskuterar fortfarande för- och nackdelarna internt och kommer att ta ett beslut snart. Vad tycker du? Hur hanterar du front-end beroenden i ett distribuerat team?