Het beheer van afhankelijkheden kan lastig zijn. Toen ik een paar weken geleden bij dojo4 kwam werken, was het geweldig om een ruby on rails-projectrepository te clonen, een bundle install uit te voeren en vervolgens de app te kunnen draaien met rails s. Voor hen die niet bekend zijn met het beheer van ruby on rails-afhankelijkheden, staan de gems die nodig zijn om de toepassing te draaien, in een bestand met de naam Gemfile. De bundle-toepassing leest deze gemfile en downloadt en installeert alle gems die nog niet op uw computer staan. Niet alleen maakt dit het eenvoudig om de toepassing snel en zonder veel inspanning op te zetten, het maakt het ook eenvoudig om deze afhankelijke gems bij te werken wanneer een nieuwe versie wordt uitgebracht. Het uitvoeren van bundle update of het bijwerken van de gemfile en het opnieuw uitvoeren van bundle install maakt dit een eenvoudig proces dat garandeert dat elke andere gebruiker van de app ook de nieuwe versie gebruikt (mits we de wijzigingen delen via bronbeheer). Dit is een geweldige workflow voor de serverside van de dingen, maar wat met de clientsite?

Naarmate clienttoepassingen complexer worden, hebben we vaak de hulp nodig van bibliotheken en frameworks aan de clientkant. Bij dojo4 downloaden we momenteel de bestanden die we nodig hebben en plaatsen we de vereiste bestanden handmatig in de bronbeheer en commit ze. De bestanden staan onder bronbeheer, dus ten minste krijgt iedereen die bestanden en we kunnen een versie-upgrade terugdraaien, maar het is een beetje rommelig. Om de bibliotheekbestanden bij te werken, moeten we het handmatige proces herhalen. Aan de serverside is het ook echt leuk dat afhankelijkheidsbeheertaken minder sterk gekoppeld zijn aan de toepassingscode zodat het bijwerken en terugdraaien van versies eenvoudiger is. Helaas was er tot voor kort geen goede manier om afhankelijkheden voor de frontend te beheren. Tot recentelijk.

In september vorig jaar bracht Twitter Bower uit, wat een "algemene, onafhankelijke oplossing biedt voor het probleem van front-end pakketbeheer". Bower biedt dezelfde mogelijkheden voor de front-end applicatie als bundle voor de back-end: een centrale lijst van afhankelijkheden in één bestand, eenvoudige installatie- en update-opdrachten, en een zekere scheiding tussen app-code en commits. Tijdens het onderzoeken hoe we hiervan konden profiteren in onze standaard ruby on rails-toepassing, werd ik door de makers van Bower verwezen naar de bower-rails gem, die Bower integreert in de ruby on rails-directorystructuur en enkele rake-opdrachten toevoegt om Bower-opdrachten uit te voeren. Nu kan een ontwikkelaar in plaats van handmatig bibliotheekbestanden naar de app-repo te committen, rake bower:install [pakketnaam] doen en de nieuwste versie van dat pakket wordt geïnstalleerd in de asset pipeline en wordt toegevoegd aan de lijst van vereiste pakketten. Een nieuwe ontwikkelaar kan dan de app-code downloaden en na het uitvoeren van bundle install, kan rake bower:install uitvoeren en alle front-end afhankelijkheden worden geïnstalleerd in de juiste map in de ruby on rails asset pipeline voor onmiddellijk gebruik.

Persoonlijk vind ik deze benadering erg leuk en hoop dat we de front-end bibliotheken die handmatig zijn toegevoegd, kunnen omzetten naar de Bower-benadering. We bespreken intern nog de voordelen en nadelen en zullen spoedig een beslissing nemen. Wat denk jij? Hoe beheer je front-end afhankelijkheden in een gedistribueerd team?