Fichier Make pour les Développeurs — Automatisez les Tâches Sans Script Bash Débile

Vous savez comment ça va. Un projet commence proprement. Puis quelqu'un ajoute un run.sh. Puis build.sh. Puis un deploy.sh qui source un .env et appelle les deux premiers dans un ordre spécifique, et soudainement il y a six fichiers shell que personne ne veut toucher et un README qui dit « voir le dossier scripts ».

Faites les corrections nécessaires. Un Makefile dans le répertoire racine, make test, terminé.

Cela ne concerne pas les systèmes de construction en C. Make existait avant Linux et était initialement conçu pour la compilation basée sur les dépendances — mais son mécanisme fondamental (des cibles nommées exécutant des commandes shell) le rend un outil de tâche parfaitement adapté à n'importe quelle stack. Node, Python, Go, Rust, Docker, tout ce que vous construisez.

Comment Make fonctionne-t-il réellement

Un Makefile est une liste de cibles. Chaque cible a un nom, des dépendances optionnelles et un bloc de commande shell :

.PHONY: build test lint clean

build:
	npm run build

test:
	npm test

Deux choses qui dérangent tout le monde lors de leur première utilisation :

• L'indentation doit être un caractère tab réel, pas des espaces. Chaque éditeur qui convertit automatiquement les tabs va silencieusement briser votre Makefile jusqu'à ce que vous configuriez autrement. Cela a été vrai depuis 1977 et Make ne vous pardonnera jamais d'utiliser des espaces.
• Par défaut, Make pense que les noms de cibles sont des noms de fichiers. Si un fichier appelé build existe dans le répertoire racine, make build ne fait rien parce que Make pense que la cible est déjà « construite ». La solution est .PHONY.

Déclarer chaque cible qui n'est pas un nom de fichier réel comme .PHONY. En pratique, les Makefiles d'outils de gestion de tâches déclarent chaque cible parce que aucune d'entre elles ne produit de fichiers. Votre .PHONY ligne se termine par la première ligne du modèle ci-dessous.

Variables et surcharges de ligne de commande

Make possède sa propre syntaxe de variable — ressemble à celle du shell mais fonctionne différemment :

DOCKER_IMAGE = myapp
TAG = latest

build:
	docker build -t $(DOCKER_IMAGE):$(TAG) .

Surcharge depuis la ligne de commande : make build TAG=v1.2.3. Aucune modification de fichier nécessaire pour les builds versionnés ou les déploiements spécifiques à l'environnement. Les variables d'environnement du shell sont également disponibles automatiquement — $(HOME), $(PATH), tout ce qui se trouve dans votre environnement lors de l'exécution de make.

Un modèle de Makefile prêt à l'emploi

Copiez cela, supprimez ce qui ne s'applique pas, ajustez les commandes selon votre stack :

.PHONY: install build test lint clean run docker-up docker-down help

# --- Config -------------------------------------------------------------------
DOCKER_COMPOSE = docker compose
APP_NAME = myapp

# --- Default target -----------------------------------------------------------
help:
	@echo "Available targets:"
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "  %-15s %s\n", $$1, $$2}'

# --- Dev ----------------------------------------------------------------------
install: ## Install dependencies
	npm ci

run: ## Start the dev server
	npm run dev

build: ## Build for production
	npm run build

# --- Quality ------------------------------------------------------------------
lint: ## Run the linter
	npm run lint

test: ## Run the test suite
	npm test

test-watch: ## Run tests in watch mode
	npm run test:watch

# --- Docker -------------------------------------------------------------------
docker-up: ## Start services via docker compose
	$(DOCKER_COMPOSE) up -d

docker-down: ## Stop and remove containers
	$(DOCKER_COMPOSE) down

docker-logs: ## Tail container logs
	$(DOCKER_COMPOSE) logs -f

# --- Cleanup ------------------------------------------------------------------
clean: ## Remove build artifacts and caches
	rm -rf dist node_modules/.cache .next

Le help cible utilise un motif grep + awk pour extraire les commentaires inline et les formater en documentation. Exécutez ## et vous obtenez une liste triée de toutes les cibles avec leurs descriptions — aucune documentation séparée à maintenir. C'est le morceau le plus volé de l'histoire des Makefiles, et pour une bonne raison. make help Chaînage de cibles pour les environnements de CI

Make gère les dépendances nativement. Liste les cibles comme dépendances pour les exécuter dans l'ordre :

exécute le lint, puis le test, puis la compilation. Si une étape sort avec un code de sortie non nul, Make s'arrête. C'est le comportement correct d'un CI — échouer bruyamment, ne pas cacher silencieusement l'étape défaillante.

ci: lint test build ## Full CI check (lint -> test -> build)

make ci Suppression de l'affichage et exécution de commandes multi-lignes

Par défaut, Make affiche chaque commande avant de l'exécuter. Précédez-la par

pour l'annuler : @ Pour des commandes qui s'étendent sur plusieurs lignes, utilisez

setup:
	@echo "Setting up project..."
	@cp .env.example .env
	@npm ci
	@echo "Done."

— elle s'arrête en cas d'échec, contrairement aux points-virgules qui continuent malgré tout : && Quand Make est l'outil inapproprié

migrate:
	npm run db:migrate && \
	npm run db:seed && \
	echo "Migration complete"

Make est fourni sur macOS (via les outils de ligne de commande Xcode) et sur chaque distribution Linux. Aucune étape d'installation, aucun conflit de version, aucune friction pour la plupart des équipes de développement.

Où il se démontre insuffisant :

— WSL fonctionne bien, mais Windows natif n'a pas make sans Chocolatey, Scoop ou le port GnuWin32. Si votre équipe est native Windows,

• Fenêtres simplement est une alternative proche conçue spécifiquement pour combler ce vide. Logique complexe
• — Make n'est pas une langue de programmation. Les conditions et les boucles existent mais sont vraiment maladroites. Si votre logique de construction nécessite des branches réelles, écrivez un script approprié. Commandes shell cross-platform
• , et d'autres outils Unix n'existent pas sur Windows natif. — rm -rf, cpTâche (basée sur Go) gère cela grâce à un support natif des commandes cross-platform. Pour la plupart des équipes backend et fullstack sur Mac ou Linux, Make est la solution pragmatique par défaut. C'est ennuyeux, mais de la meilleure manière — rien à installer, rien à mettre à jour, rien qui se casse lors d'une mise à jour de dépendance.

Maintenir votre Makefile propre

Quand un Makefile grandit avec plusieurs contributeurs et des mergers, les indentations et espaces dérivent. Puisque Make est sensible à l'espace, un espace en trop au lieu d'un tab brise silencieusement une cible sans message d'erreur utile.

IO Tools’ formateur de Makefile normalise les indentations et nettoie les espaces sans toucher la logique — utile comme vérification de santé avant chaque commit. Makefile pour les développeurs — Automatiser les tâches sans Bash spaghetti 2

Vous aimerez peut-être aussi