Gregory's ServerЕсли я чему-то и научился за несколько лет работы на StopGame, так это тому, что свой специфический велосипед, решающий ровно твою задачу, всегда будет проще и быстрее, чем инструмент, заточенный решать задачи большого количества людей.
Долгое время использовал пакет semantic-release для того, чтобы обновлять номер версии при каждом новом деплое.
Сегодня заменил его на самописный скрипт в несколько строчек, который пару раз дёргает git, проходится по всем коммитам в ветке с последнего тега, определяет подходящий номер версии и пушит тег в репозиторий в Gitlab.
Работает на 3 минуты(!) быстрее, чем semantic-release, который, в моём случае, выполнял ровно ту же задачу «выдай мне новый номер версии и запуш его в репозиторий».
При том, судя по тому, что время сборки росло с количеством коммитов, semantic-release зачем-то сканировал весь репозиторий.
 5 comments
 Да почти всегда на самом деле :) Это и в быту так. Надо тебе открутить какую-то фиговину, ты всегда сначала берёшь готовые пассатижи. А если нет, то идёшь и покупаешь. И только со временем, может быть, изготавливаешь приспособу, которая проще, лучше и эффективнее.   @dotterian узкие решения работают быстрее НО в них сложнее погружается. Это проблема больших банков где много самописных фреймворков - опыт становится не релевантным для рынка. У vk такая есть особенность когда почти все свое и через 3 года работы в vk ты абсолютно не актуален для рынка потому что нет опыта работы на массовых решениях |
@dotterian Зависит.
Иногда лучше сначала воспользоваться широкоуниверсальным инструментом (который по определению будет более громоздким, потому что надо учесть те вещи, которые ты не учел бы, если бы делал только под свою систему), и только потом, когда параметры системы определены, мы знаем, что от нее хотим, но что-то в компоненте не устраивает (медленно работает, например, или просто блоат), уже строить свои костыли и велосипеды строго под задачу.
Это все та же басня про преждевременную оптимизацию.
@dotterian Зависит.
Иногда лучше сначала воспользоваться широкоуниверсальным инструментом (который по определению будет более громоздким, потому что надо учесть те вещи, которые ты не учел бы, если бы делал только под свою систему), и только потом, когда параметры системы определены, мы знаем, что от нее хотим, но что-то в компоненте не устраивает (медленно работает, например, или просто блоат), уже строить свои костыли и велосипеды строго под задачу.