Air: rechargement continu pour applications Go en développement local
Rechargement en direct pour les applications Go. L'ancien champ build.bin est obsolète et sera supprimé dans une prochaine version, préférez donc le formulaire de point d'entrée à l'avenir.
En bref
- De quoi s’agit-il ?
- Utilitaire Go qui surveille les changements de fichiers et reconstruit/relance votre application sans intervention manuelle, intégrant éventuellement un proxy pour rechargement automatique du navigateur.
- À qui s’adresse-t-il ?
- Air s'adresse aux développeurs Go construisant des services web ou CLI en local et cherchant à éliminer les cycles manuels build-test. Les équipes déployant Go en production n'utiliseraient pas Air (l'outil s'arrête au développement).
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions. GPL-3.0 est une licence copyleft : si vous distribuez un logiciel qui l’inclut, vous devez publier le code source de ce logiciel sous la même licence. Un usage interne, sans distribution, ne déclenche pas cette obligation.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 20 jours.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Portée et positionnement dans le workflow Go
Air est un utilitaire de rechargement en direct écrit en Go pour développer des applications Go. Le README pose explicitement ses limites dès le début: air n'a rien à voir avec le hot deploy en production. Ce périmètre détermine tous les choix de conception. Air surveille les fichiers source, recompile votre binaire sur modification, et le relance; cela élimine l'alternance manuelle terminal-éditeur pendant les cycles de développement. Le README note que vous laissez air tourner et vous focalisez sur votre code. Le dépôt accumule 23 930 étoiles et 925 forks; la branche par défaut s'appelle master et la dernière mise à jour remonte au 1er août 2026 (v1.67.4).
Méthodes d'installation et chemins multiples
L'installation recommandée utilise go install github.com/air-verse/air@latest (nécessite Go 1.25+), l'utilisateur devant vérifier que $GOPATH/bin est dans son PATH (exporté via export PATH="$PATH:$(go env GOPATH)/bin"). Les chemins alternatifs couvrent go get -tool pour une installation au niveau du projet (air utilisé ensuite via go tool air -v), le script install.sh téléchargeable (curl -sSfL ... | sh -s --), goblin.run, Homebrew (brew install go-air), Scoop (scoop install air), mise (mise use -g air), et l'image Docker cosmtrek/air depuis Docker Hub. Le README énumère ces options sans évaluation de préférence au-delà de la recommandation pour go install.
Configuration TOML et override en ligne de commande
Air cherche d'abord .air.toml dans le répertoire courant avant d'utiliser les paramètres par défaut. Exécuter air init crée un .air.toml avec les paramètres par défaut; air le prend en charge automatiquement. La commande air -c .air.toml pointe explicitement vers un fichier. Le fichier exemple air_example.toml dans le dépôt énumère toutes les options (ne pas reproduites dans le README). Les champs de configuration peuvent être surchargés par des arguments de ligne de commande: air --build.cmd "go build -o bin/api cmd/run.go" --build.entrypoint "./bin/api" définit la commande de compilation et le point d'entrée sans fichier. Le champ obsolète build.bin est déprécié; build.entrypoint (chaîne ou tableau) est le successeur recommandé décrivant comment exécuter le binaire compilé.
Arguments de line de commande et séparation air vs binaire
Les arguments passés après air sont transmis au binaire construit: air bench exécute ./tmp/main bench, air server --port 8080 exécute ./tmp/main server --port 8080. L'argument -- sépare les options pour air de celles pour le binaire: air -- -h transmet -h au binaire sans passer d'options à air, air -c .air.toml -- -h utilise un fichier config spécifique et passe -h au binaire. Le mode debug air -d imprime tous les journaux. L'option de bannière de démarrage misc.startup_banner personnalise ce qu'air affiche au lancement (défaut: ASCII art avec version; peut être vide ou remplacé par du texte personnalisé).
Règles de surveillance et rééxecution de commandes
Au-delà de la recompilation par défaut, les blocs [[build.rules]] dans la configuration permettent d'exécuter une commande alternative quand certains fichiers changent. Une règle nécessite au moins un matcher include_* (glob de fichier) et supporte exclude_regex, ainsi qu'un délai de rebond (débounce) en millisecondes. Cela s'avère utile pour les changements front-end (CSS/JS), la génération de code (templ, protobuf) ou d'autres tâches sans recompilation Go. Le README énumère ces capacités mais sans exemple en détail.
Proxy navigateur et rechargement automatique
Air peut placer un proxy devant votre application web. Vous accédez à proxy_port (par défaut un port configuré), air transmet les requêtes à app_port (votre application), et après une compilation réussie, il injecte un script de rechargement automatique dans la réponse. Cette injection ne fonctionne que si le HTML contient une balise </body> et repose sur le fait que air peut modifier les réponses HTTP en transit. Les fichiers statiques ne déclenchent un rechargement que s'ils sont explicitement couverts par les règles de surveillance (sinon air ignore leurs modifications). Cette fonctionnalité rapproche Air du workflow du front-end où chaque sauvegarde d'un fichier source rafraîchit le navigateur.
Intégration Docker et contextes de conteneur
L'image officielle cosmtrek/air sur Docker Hub offre Air pré-installé. Le README montre un exemple docker run montant le projet courant comme /app et mappant les ports. Il fournit aussi un wrapper de fonction shell transformant air en commande shell ordinaire et une définition de service Docker Compose pour intégrer Air dans un environnement multi-conteneur. Pour les projets qui préfèrent une image personnalisée, le README inclut un Dockerfile qui installe Air via go install, monte le code et configure le répertoire de travail. Les images statiques pré-construites ne sont pas discutées.
Développement interne et licence GPL-3.0
Pour développer Air lui-même, make ci installe les dépendances (Go 1.25+ requis) et make install compile le binaire. La section motivation du README relate l'histoire: l'auteur développait des sites web Go avec gin, a essayé l'outil fresh, l'a trouvé insuffisamment flexible et l'a réécrit en tant que air. Le projet est sous licence GPL-3.0, accordant la liberté de copier, distribuer et modifier le logiciel; les versions modifiées distribuées doivent conserver la même licence et accès au code source. La licence exclut toute garantie pour le logiciel libre. Elle ne comporte aucune déclaration sur la sécurité, la performance ou les niveaux de support formalisés.
Conclusion éditoriale
Air s'adresse aux développeurs Go construisant des services web ou CLI en local et cherchant à éliminer les cycles manuels build-test. Les équipes déployant Go en production n'utiliseraient pas Air (l'outil s'arrête au développement). Avant adoption, installez via go install (Go 1.25+ requis), exécutez air init pour générer .air.toml, et testez le proxy navigateur si vous développez une UI web.
Notes de la communauté