ЯжПрограммист.com

В таком случае Go Modules будет удобнее, так как он позволяет легко обновлять зависимости. Но важно тестировать обновления, чтобы избежать проблем с совместимостью. Можно использовать инструменты, такие как go list -m -u all, чтобы проверить доступные обновления.

А если я хочу использовать vendoring, но не хочу увеличивать размер репозитория? Есть ли способы оптимизировать это? И если да, то какие? Хочется попроще варианты. 

Можно использовать .gitignore, чтобы исключить ненужные файлы из папки vendor, например, тесты или документацию. Также можно использовать сжатие истории Git, чтобы уменьшить размер репозитория. Правда полностью избежать увеличения размера не получится.

Ярик, а как быть с зависимостями, которые не поддерживают Go Modules? Например, старые библиотеки. Полоценной работы тогда не получится? Или есть какиее-то обходные пути?

Для таких библиотек можно использовать vendoring или инструменты, такие как dep, которые поддерживают старые проекты. Но лучше по возможности переходить на библиотеки, которые поддерживают Go Modules.

Тогда у меня меня еще вопрос. А что ты думаешь о монорепозиториях? Они могут помочь в управлении зависимостями? Или они тут ни к чему?

Монорепозитории могут быть полезны, если у тебя много взаимосвязанных проектов. Они упрощают управление зависимостями между ними. Однако они также требуют более сложной настройки CI/CD и могут увеличить сложность разработки.

Спасибо за детальный разбор вопросов.  Теперь я лучше понимаю, как управлять зависимостями в крупных проектах. А какие еще советы ты можешь дать, чего упустили тут?

Всегда документируй зависимости и их версии - это основа. Используй инструменты для автоматической проверки уязвимостей. И не забывай тестировать обновления зависимостей перед их внедрением. Удачи в разработке! 😊

Спасибо большое за подробные объяснения еще раз)
Теперь я готов выбрать подходящий подход для своего проекта. Как-то немного информация улеглась по  полочкам.