package.json مقابل go.mod: أين اختفى حقل الإصدار؟
إذا انتقلت من JavaScript إلى Go، فسيُفاجئك أمر واحد.
في ملف package.json يكون الإصدار في الأعلى تماماً. يمكنك قراءته، وتغييره في طلب سحب (pull request)، والبحث عنه. إنه حقيقة تعيش داخل الكود الخاص بك.
الآن افتح ملف go.mod. لن تجد الإصدار هناك.
هذا ليس خطأً، بل هو خيار.
لا تستخدم Go حقل إصدار للموديول (module) الخاص بك، بل تستخدم بدلاً من ذلك وسوم git (git tags).
لتحديد إصدار في Go، عليك القيام بما يلي:
git tag v1.2.3git push origin v1.2.3
وسم git هو المصدر الوحيد للحقيقة. عندما يقوم شخص ما بتشغيل go get ، تبحث Go في وسوم المستودع (repository tags) الخاص بك للعثور على الالتزام (commit) الصحيح.
يتميز هذا التصميم بنقطة قوة رئيسية؛ حيث لا يمكن للإصدار أبداً أن يشير إلى الكود الخاطئ. في npm، يمكن أن يبتعد الكود المنشور عن المصدر الموسوم (tagged source). أما في Go، فهما الشيء نفسه لأن الإصدار هو مؤشر (pointer) إلى التزام (commit) معين.
ومع ذلك، فإن هذا يغير سير عملك (workflow) بعدة طرق:
- العثور على إصدارك يتطلب أمراً؛ إذ يجب عليك تشغيل
git describe --tagsبدلاً من النظر في ملف. - تحديثات الإصدار (version bumps) لا تظهر في مراجعات الكود (code reviews). فدفع الوسم (tag push) ليس تغييراً في الكود، لذا لا يظهر في طلب السحب (pull request).
- تستخدم عمليات البناء المحلية (local builds) إصدارات وهمية (pseudo-versions). فإلى أن تقوم بوسم التزام (commit) ما، سترى سلسلة طويلة من الأرقام والرموز (hashes) بدلاً من إصدار نظيف مثل
v1.2.3. - الإصدارات الرئيسية (major versions) تغير مسار الاستيراد (import path) الخاص بك. في npm، تقوم بتغيير رقم الإصدار ولكنك تحتفظ باسم الحزمة. أما في Go، فإن الإصدار v2 وما فوق يتطلب تغييراً في المسار مثل
/v2. وهذا يسمح للبرنامج باستخدام الإصدارين v1 و v2 من نفس المكتبة في نفس الوقت دون حدوث تعارضات.
تحتفظ معظم الأنظمة البيئية (ecosystems) الأخرى بالإصدار في ملف:
- Node:
package.json - Rust:
Cargo.toml - Python:
pyproject.toml - Java:
pom.xml - .NET:
.csproj
Go مختلفة، فهي تعتمد على وسوم git فقط.
إذا كنت تريد أن يظهر ملف Go binary الخاص بك إصداراً نظيفاً، يمكنك حقنه أثناء عملية البناء باستخدام ldflags. كما يستخدم العديد من المطورين أدوات مثل goreleaser لأتمتة عملية الوسم والإصدار.
يمثل النموذجان أولويات مختلفة:
- الإصدارات القائمة على الملفات سهلة القراءة والمراجعة، لكن الخطر يكمن في إمكانية ابتعاد الملف عن الكود الفعلي.
- الإصدارات القائمة على الوسوم يستحيل تزييفها، لكن الثمن هو أنها أصعب في الرؤية والإدارة.
اختارت Go نموذج الوسوم لضمان مطابقة البيان (manifest) للكود دائماً.
لأولئك الذين يقومون بنشر أكواد Go: كيف تجدون نموذج "الوسوم فقط" (tag-only model) في عملكم اليومي؟ هل ستغيرونه؟
المصدر: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301