La gestione delle dipendenze può essere complicata. Quando sono entrato a far parte di dojo4 alcune settimane fa, è stato fantastico clonare un repository di un progetto ruby on rails, essere in grado di eseguire un bundle install e quindi eseguire l'app con rails s. Per coloro che non sono familiari con la gestione delle dipendenze di ruby on rails, le gemme necessarie per eseguire l'applicazione sono elencate in un file chiamato Gemfile. L'applicazione bundle legge questo gemfile e scarica e installa eventuali gemme che non sono ancora sul tuo computer. Non solo questo rende facile far funzionare l'applicazione correttamente in modo rapido e senza troppo sforzo di configurazione, ma rende anche facile aggiornare quelle gemme dipendenti quando viene rilasciata una nuova versione. Eseguire bundle update o aggiornare il gemfile ed eseguire nuovamente bundle install rende questo un processo semplice che garantisce che ogni altro utente dell'app utilizzerà anche la nuova versione (purché condividiamo le modifiche tramite il controllo della sorgente). Questo è un ottimo flusso di lavoro per il lato server, ma cosa succede per il lato client?

Man mano che le applicazioni client diventano più complesse, spesso abbiamo bisogno dell'assistenza di librerie e framework anche sul client. Attualmente, in dojo4, scarichiamo i file di cui abbiamo bisogno e li inseriamo manualmente nel controllo della sorgente e li committiamo. I file sono sotto controllo della sorgente, quindi almeno tutti otterranno quei file e possiamo ripristinare un aggiornamento della versione, ma è un po' disordinato. Per aggiornare i file della libreria dobbiamo ripetere il processo manuale. Anche sul lato server, è molto comodo che i compiti di gestione delle dipendenze siano meno strettamente accoppiati al codice dell'applicazione in modo che l'aggiornamento e il ripristino delle versioni siano più semplici. Purtroppo, non c'era un modo efficace per gestire le dipendenze per il front end. Fino a poco tempo fa.

A settembre dello scorso anno, Twitter ha rilasciato Bower, che offre "una soluzione generica e non opinabile al problema della gestione dei pacchetti front-end". Bower fornisce le stesse capacità per l'applicazione front-end che bundle fornisce per il back-end: un elenco centrale delle dipendenze in un file, comandi di installazione e aggiornamento facili e una certa separazione dai commit del codice dell'app. Mentre studiavo come potevamo sfruttare questo nella nostra applicazione ruby on rails standard, i creatori di Bower mi hanno indirizzato alla gemma bower-rails, che integra bower nella struttura delle directory di ruby on rails e aggiunge alcuni comandi rake per eseguire i comandi bower. Ora, invece di committare manualmente i file della libreria nel repository dell'app, uno sviluppatore può eseguire rake bower:install [nome del pacchetto] e l'ultima versione di quel pacchetto verrà installata nella pipeline degli asset e verrà aggiunta all'elenco dei pacchetti richiesti. Un nuovo sviluppatore può quindi scaricare il codice dell'app e, dopo aver eseguito bundle install, può eseguire rake bower:install e tutte le dipendenze front-end verranno installate nella directory corretta nella pipeline degli asset di ruby on rails per l'uso immediato.

Personalmente, mi piace molto questo approccio e spero che possiamo convertire le librerie front-end aggiunte manualmente all'approccio bower. Stiamo ancora discutendo internamente i vantaggi e gli svantaggi e prenderemo presto una decisione. Cosa ne pensi? Come gestisci le dipendenze front-end in un team distribuito?