tool directive

تتبّع أدوات المشروع داخل go.mod tool directive

منذ Go 1.24، يمكن تسجيل تبعية أداة قابلة للتنفيذ (linter، مولّد كود...) داخل go.mod عبر توجيه tool، فتُتبَّع بإصدار محدَّد دون الحاجة لملف tools.go الوهمي القديم.

قبل Go 1.24، تتبُّع أداة كتبعية (مثل مولّد كود يُشغَّل بـ go run أو go install) كان يحتاج حيلة شائعة: ملف tools.go بعلامة بناء تستثنيه من الترجمة العادية، يحتوي استيرادًا فارغًا (blank import) بـ _ فقط لإجبار go.sum على تتبّع إصدار الأداة. توجيه tool الجديد يلغي هذه الحيلة كليًا: سطر tool داخل go.mod يسجّل الأداة كتبعية بإصدار محدَّد مباشرة، بلا أي كود وهمي.

الإضافة تتم عبر go get -tool، وتشغيل الأداة المسجَّلة عبر go tool، فتضمن أن كل من يبني المشروع يستخدم بالضبط نفس إصدار الأداة المثبَّت بـ go.sum.

الصياغة

tool module/path/cmd/toolname

go get -tool module/path/cmd/toolname@version
go tool toolname [args...]

📄 مثال

// go.mod
module github.com/user/myapp

go 1.24

tool golang.org/x/tools/cmd/stringer

require (
  golang.org/x/tools v0.30.0 // indirect
)

أهم النقاط

العنصر	الوظيفة
tool path	سطر داخل go.mod يسجّل أداة كتبعية بإصدار محدَّد، بلا استيراد وهمي بالكود
go get -tool path@version	يضيف السطر تلقائيًا لـ go.mod ويحدّث go.sum
go tool name	يشغّل الأداة المسجَّلة بإصدارها الدقيق المحدَّد في go.mod

💡 نصائح عملية

احذف ملف tools.go القديم (الاستيراد الوهمي بـ _) بعد الانتقال لتوجيه tool — لم يعد له داعٍ
استخدم go get -tool path@none لإزالة أداة من go.mod بدل حذف السطر يدويًا

⚠️ أخطاء شائعة

إبقاء نمط tools.go القديم بجانب توجيهات tool الجديدة — يسبّب ازدواجية غير ضرورية بإدارة نفس التبعية
تثبيت أداة عالميًا بـ go install بدل تسجيلها بـ tool داخل go.mod — يفقد الفريق ضمان استخدام نفس إصدار الأداة بكل جهاز

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار GO الكامل بالعربي.