Blog / Flintable - Introduction à Flint
3 min - 12 May 2025
Flint est un formateur de code intégré à Git qui permet à chaque développeur de travailler avec son style préféré en local tout en maintenant un style uniforme à distance. En appliquant automatiquement deux passes de formatage (« local » et « remote ») lors des opérations de pull et de push, Flint évite le bruit de mise en forme dans les commits et les revues de code.
En tant qu’artisans du code, nous avons chacun nos préférences : style d’accolades, taille d’indentation, longueur maximale des lignes… Pourtant, en équipe, ces choix personnels peuvent diverger, encombrer les pull requests et ralentir les revues. Les outils existants comme Prettier imposent des règles strictes et uniforme, pratiques mais peu flexibles lorsque l’on souhaite conserver une touche personnelle.
Flint comble ce fossé : vous codez dans votre style local, puis Flint reformate automatiquement pour correspondre au style de l’équipe avant de synchroniser le dépôt distant. Résultat : moins de friction cognitive, des diffs plus clairs et une équipe probablement plus sereine.
Prettier se présente comme un formateur « opinioné », réduisant la surface de configuration au prix d’un contrôle granulaire. Si vous tombez sur un style qui ne vous convient pas, vous n’avez d’autre choix que de désactiver Prettier ou d’ajouter des commentaires // prettier-ignore
un peu partout.
On peut aussi s’appuyer sur ESLint pour l’auto-formatage, mais cela implique souvent de bricoler des dizaines de règles, d’ajuster les configs projet par projet et de jongler continuellement avec des overrides divergents. Au final, c’est beaucoup de temps perdu en micro-ajustements et de la confusion constante.
Selon la théorie de la charge cognitive, notre mémoire de travail ne peut gérer qu’un nombre limité de « chunks ». À chaque fois que l’on change de style – indent, accolade, retour à la ligne – on crée une charge supplémentaire qui nous détourne de la logique et du design de notre code. Flint propose un formatage en deux modes :
Local : vous codez dans votre style habituel, sans interruption.
Remote : Flint reformate selon les conventions de l’équipe juste avant la synchronisation.
Cette séparation vous permet de rester concentré sur le problème à résoudre et de conserver un modèle mental stable lors de la revue de code.
Flint s’intercale, entre autre, dans vos git pull
et git push
, insérant les étapes de formatage de façon transparente. Vous n’avez rien de nouveau à apprendre : continuez simplement à utiliser Git comme d’habitude.
Un simple fichier flint.config.json
liste vos linters, chacun avec des commandes local
et remote
. Par exemple, vous pouvez exécuter ESLint avec --config eslint.local.config.js
en local et une version plus stricte eslint.remote.config.js
à distance.
Lors de certaines opérations, Flint crée un commit temporaire pour garder la trace de la transition de style. Les diffs correspondent aux différences entre le commit précédent dans votre style, et le code actuel dans votre style.
Installez Flint en utilisant le gestionnaire de paquets disponible de votre choix
Exécutez la commande flint init
à la racine de votre projet. Cette action crée un dossier caché et un fichier de configuration de base.
Modifiez le fichier flint.config.json
pour ajuster les différentes options de formatage : définissez vos commandes « local » et « remote », les types defichiers à inclure, et toute autre règle propre à votre workflow.
Si ce n’est pas déjà fait, lancez git init
pour créer votre dépôt local, puis ajoutez une télécommande git remote add
vers votre hébergement Git.
Poursuivez votre travail ainsi que votre utilisation habituelle de Git : Avant chaque pull, Flint applique d’abord le formatage « remote » puis synchronise vos changements. Avant chaque push, Flint conserve votre style local, puis formate selon la configuration distante juste avant l’envoi.
Cette intégration en douceur permet de profiter de Flint sans encombrer vos habitudes ni mentionner d’outil de linting ou de gestion de paquets spécifique.
Pour tester Flint rapidement, cliquez ici.
- Anthony Fu, “Why I don’t use Prettier”
- Artem Zakirullin, “Cognitive load is what matters”
- Prettier