𝗣𝗮𝗰𝗸𝗮𝗴𝗲.𝗷𝘀𝗼𝗻 проти 𝗴𝗼.𝗺𝗼𝗱: Куди зникло поле версії?

Якщо ви переходите з JavaScript на Go, одна річ вас здивує.

Відкрийте файл package.json. Ви побачите поле version прямо зверху. Його легко прочитати. Ви можете змінити його в pull request. Воно знаходиться безпосередньо у вашому коді.

Тепер відкрийте файл go.mod.

Версії там немає. Це не помилка. Це вибір.

Go не використовує поле версії для вашого власного модуля. Замість цього він використовує git tags.

Як це працює: • Ви запускаєте git tag v1.2.3 • Ви відправляєте (push) тег у свій репозиторій • Цей тег стає вашою версією

Коли хтось запускає go get, Go шукає відповідний коміт у ваших git tags. Тег є єдиним джерелом істини.

Ця архітектура має вагому перевагу. Версія ніколи не може вказувати на неправильний код. В npm опублікований код і поле версії можуть розходитися. В Go це одне й те саме. Версія — це і є коміт.

Однак це змінює ваш робочий процес:

Приклад: v1 використовує github.com/you/my-app v2 використовує github.com/you/my-app/v2

Це дозволяє одній програмі використовувати дві різні мажорні версії однієї й тієї самої бібліотеки без конфліктів.

Більшість інших мов зберігають версію у файлі: • Node: package.json • Rust: Cargo.toml • Python: pyproject.toml • Java: pom.xml

Go є винятком. Він суворо покладається на git tags.

Якщо вам бракує досвіду роботи з npm, ви можете вставити версію у свій бінарний файл під час збірки за допомогою ldflags. Це дозволить вашому застосунку реагувати на команду перевірки версії.

Компроміс простий: Поле версії легко читати та перевіряти, але воно може брехати. Git tag важко побачити, але він завжди правдивий.

Go обрав істину замість зручності.

До розробників Go: Чи є це найкращою моделлю? Чи віддали б ви перевагу полю версії в go.mod, якби інструменти перевіряли його на відповідність git tag?

Джерело: https://dev.to/dalirnet/packagejson-vs-gomod-where-did-the-version-field-go-3301