مُصنف Make للمساهمين — تلقائيّة المهام دون تسلسلات Bash المُضطربة

تُعرفُ طريقة البدء. يبدأ المشروع نظيفًا. ثم يضيف شخص ما run.sh. ثم build.sh. ثم deploy.sh يُستخرج من .env ويعمل على أولين في ترتيب محدد، وفجأة تظهر ملفات شيل ستة لا يرغب أحد في تغييرها، وملف "README" ينص على "انظر إلى مجلد السيناريوهات."

أعد التصحيحات. واحد Makefile في جذر المشروع، make test، مكتمل.

هذا ليس متعلقًا بأنظمة بناء C. تم إنشاء Make قبل نظام لينكس، وكان مصممًا أصلاً للاختبارات المبنية على الاعتماد — لكن ميكانيكية النواة (العناصر المُسمّاة التي تُنفذ أوامر شيل) تجعله مُستخدمًا بشكل مثالي كمُدير مهام لأي نظام بناء. سواء كان ذلك Node، أو Python، أو Go، أو Rust، أو Docker، أو أي شيء تُبنى عليه.

كيف يعمل Make فعليًا

يُعدّ ملف Make قائمة بأهداف. كل هدف يحتوي على اسم، واعتماد اختياري، وحقل أوامر شيل:

.PHONY: build test lint clean

build:
	npm run build

test:
	npm test

اثنين من الأمور التي تُسبب صعوبة لجميع الناس عند أول تفاعل:

• يجب أن تكون التمديدات حقيقية من نوع "Tab"وغير مساحة. كل محرر يُحول التمديدات تلقائيًا سيُوقف عمل ملف Make حتى تُضبط الإعدادات بشكل آخر. هذا صحيح منذ 1977، وسترفض Make استخدام المساحات.
• بشكل افتراضي، يعتقد Make أن أسماء الأهداف هي أسماء ملفات. إذا كان ملف يُسمى build موجودًا في جذر المشروع، make build لا يفعل شيئًا لأن Make يعتقد أن الهدف تم بناؤه بالفعل. الحل هو .PHONY.

إظهار كل هدف ليس ملفًا حقيقيًا باسم كـ .PHONY. في الممارسة، يُعلن ملفات Make كمُدير مهام كل هدف لأن لا يُنتج أي ملف. سينتهي سطرك كأول سطر في النموذج التالي. .PHONY مُتغيرات وأوامر خط الطرف

يملك Make نظام مُتغيرات خاصًا — يشبه الأوامر في بيئة الشيل لكنه يُصرف بشكل مختلف:

تُغيّر من خلال خط الطرف:

DOCKER_IMAGE = myapp
TAG = latest

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

. لا حاجة لتحرير الملفات عند إجراء إصدارات مُحددة أو نشرات مُخصصة للبيئة. تُتاح المتغيرات البيئية تلقائيًا — make build TAG=v1.2.3، أي ما هو موجود في بيئة التشغيل عند تشغيل make. $(HOME), $(PATH)نموذج جاهز لملف Make

أعد نسخ هذا، حذف ما لا يناسب، وقم بتعديل الأوامر لتناسب مكوناتك:

يستخدم هدف grep + awk لاستخراج التعليقات المُضمنة إلى وثائق مُصاغة. قم بتشغيل

.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

ال help وستحصل على قائمة مرتبة لكل هدف مع وصفه — لا حاجة لحفظ وثائق منفصلة. هذا هو أكثر قطعة مُسروقة في تاريخ ملفات Make لسبب جيد. ## ربط الأهداف للاستخدام في بيئة CI make help يُعالج Make الاعتماد بشكل مدمج. قم بوضع الأهداف كاعتماد لتشغيلها بالترتيب:

يُنفذ التحقق، ثم الاختبار، ثم البناء. إذا فشل أي خطوة، يوقف Make. هذا سلوك صحيح لبيئة CI — فشل بوضوح، لا تغطية سلسة للخطوة المُتضررة.

إخفاء طباعة الأوامر وكتابة أوامر متعددة الأسطر

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

make ci بشكل افتراضي، يُعرض Make كل أمر قبل تنفيذه. قم بوضع

لإخفاء:

لأوامر تُكتب على عدة أسطر، قم بربطها باستخدام @ — يُوقف عند الفشل، بينما السemicolon يواصل حتى لو فشل:

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

عندما يكون Make الأداة الخاطئة && يُأتي Make مع نظام macOS (من خلال أدوات خط الطرف لـ Xcode) وكل توزيعة لينكس. لا حاجة لخطوة تثبيت، ولا تعارضات إصدارات، ولا صعوبات للفرق التقنية.

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

أين يُضعف:

— يعمل WSL بشكل جيد، لكن نظام ويندوز الأصلي لا يحتوي على make بدون استخدام Chocolatey أو Scoop أو نسخة GnuWin32. إذا كان فريقك مُخصصًا لـ ويندوز،

فقط

• نوافذ هو حل مُقارب مُصمم خصيصًا لهذا الفجوة. المنطق المعقد — Make ليس لغة برمجة. توجد شروط وحلقات لكنها مُصغرة بشكل حقيقي. إذا كانت منطق بناءك يتطلب فتحات حقيقية، فقم بكتابة سكربت مناسب.
• أوامر الشيل المتعددة المنصات ، وغيرها من الأدوات المُعتمدة على نظام يونكس لا توجد على ويندوز الأصلي.
• مهمة — rm -rf, cp(مبنية على Go) تتعامل مع هذا بدعم أوامر متعددة المنصات مدمجة. للمجموعات الخلفية والكاملة على ماك أو لينكس، Make هو القيمة المُستخدمة بشكل منطقي. هي مملة بطريقة جيدة — لا حاجة لتثبيت، لا حاجة لتحديث، لا شيء يُعطل عند تحديث الاعتماد. الحفاظ على ملف Make نظيفًا

عندما ينمو ملف Make عبر مساهمين متعددين واندماجات، تبدأ التمديدات والمسافات في التغير. بما أن Make حساس للمسافات، فإن وجود مسافة بدل تمديد يُوقف هدفًا دون إشعار مفيد.

مُعدّل ملف Make لـ IO Tools

يُوحّد التمديدات ويُنظف المسافات دون التأثير على المنطق — مفيد كفحص صحي قبل التسليم. ملف Make للفريق المطور — تلقّي المهام دون تسلسل برمجي مُضطرب 2 ملف Make للفريق المطور — تلقّي المهام دون تسلسل برمجي مُضطرب 1

قد يعجبك أيضاً