Hygiène de Gemfile

Sunny Ripert
La Fabrique
Published in
4 min readSep 5, 2017
Fig 1. : Sac de nœuds représentant votre Gemfile

En Ruby, le fichier Gemfile est le fichier où nous collons les dépendances de notre application… et où nous les oublions.

Voici quelques règles issues de ma présentation à Paris.rb pour vous permettre de conserver un Gemfile sain, lisible et facile à mettre à jour sur le long terme.

Un commentaire

S’il n’y a qu’une règle à retenir c’est celle-ci : ajoutez devant chaque gemme un commentaire qui explique à quoi elle sert.

# XML Parsing library, required for our RSS feed reader
gem "nokogiri"

Le nom de la gemme suffit très rarement à comprendre à quoi elle sert, sans avoir à chercher. Avec des noms comme prawn,nokogiri et koala, vous aurez bien du mal à savoir si c’est une application web, un crawler… ou un menu de restaurant très douteux.

Vous pouvez insérer cette ligne de façon automatique avec AnnotateGem qui ajoutera la description automatique de la gemme. Mais ce commentaire doit surtout décrire à quoi sert cette librairie pour votre application. Qu’est ce qu’elle vous apporte ? Est-ce que vous ne vous servez que d’une partie de cette librairie ? Est-ce qu’elle est là pour faire fonctionner une autre gemme ?

Du contexte

Si une gemme dépend d’une version spécifique ou d’une branche git spécifique, ajoutez un commentaire qui explique pourquoi. Ça peut être à cause d’une fonctionnalité dont vous dépendez, d’une incompatibilité, d’un bug, d’un identifiant de CVE

Si une gemme n’est plus maintenue, ou que vous avez décidé de vous en séparer un jour, ajoutez # DEPRECATED en commentaire en expliquant la raison.

Enfin, ajoutez autant de liens que possible vers :

  • la réponse Stack-Overflow qui vous a amené à utiliser cette gemme ;
  • l’issue du bug qui vous pousse à utiliser cette version ;
  • la pull-request de la branche spécifique que vous utilisez.

Sans ces commentaires et ces liens, toutes ces décisions seront perdues dans l’historique de votre outil de versionnement.

En les ajoutant, vous simplifiez la mise à jour et la suppression future de vos dépendances.

Des groupes

Plutôt que de lister vos dépendances dans l’ordre d’ajout, prenez le temps de les grouper par besoin. Quelques exemples de groupes :

  • APIs
  • Logging
  • Performance
  • Authentification
  • Assets

Avec le temps, ces groupes permettent d’avoir une meilleure vue d’ensemble de l’application, de mieux comprendre les choix et d’éviter d’introduire de nouvelles gemmes qui feraient la même chose qu’une gemme déjà présente.

Toutes les dépendances

Lorsque Bundler installe les librairies listées, il installe également les dépendances de ces librairies. Si votre code dépend d’une de ces dépendances transitives sans que vous l’ayez ajoutée à votre Gemfile, vous risquez que celle-ci disparaisse après une mise à jour, même mineure.

Un lock

Le fichier Gemfile.lock sert à figer les dépendances. En l’ajoutant à votre outil de versionnement, vous vous assurez que tous les environnements et tou·te·s les développeurs·ses aient les mêmes dépendances.

Par contre, si vous codez une gemme, c’est votre fichier .gemspec qui fait foi et qui sera utilisé sur des applications avec des jeux de dépendances différents. Comme vos dépendances ne sont pas figées dans les autres applications, vous avez donc plutôt intérêt à ne pas figer votre fichier de lock lorsque vous développez votre gemme.

Un œil sur les mises à jour

Lancer bundle outdated vous listera les gemmes qui peuvent profiter d’une mise à jour, et qui mériteraient un bundle update. Tenez-vous au courant des mises à jour de sécurité et prenez un peu de temps régulièrement pour actualiser celles qui s’appliquent facilement.

Une invitation à un Gemfile plus lisible

Si vous maintenez des gemmes, je vous invite à changer votre README de :

To install this gem, add this line in your `Gemfile`:    gem "some-gem-name"

En :

To install this gem, add these lines to your `Gemfile`:    # Adds some things to your Rails app
gem "some-gem-name"

Ce petit changement peut faire en sorte que ces bonnes pratiques soient suivies dès le départ, en invitant tout le monde dans la communauté Ruby à documenter ses dépendances.

Quand vous serez prévenu d’une mise à jour de sécurité importante, que vous voudrez migrer votre application, qu’il faudra mettre à jour ou retirer des dépendances, ces petites touches d’hygiène tout au long de votre projet vous feront gagner de la sérénité et un temps substantiel.

Maintenant, répétez avec moi ce mantra : mon Gemfile est un sanctuaire. Mon Gemfile est un sanctuaire. Mon Gemfile est un sanctuaire. Mon Gemfile est…

--

--