← На главную

Зачем разработчик делает единые обёртки, если их редко используют?

03.08.2026 16:51 · hackernews

Разработчик то и дело переключается между репозиториями, и в каждом — свой набор команд. Где-то зависимости ставятся через mix deps.update, где-то сборка через ./gradlew build или mvn, а форматирование то через rust fmt, то через npm run prettier. Помнить все эти заклинания не хочется: хочется говорить просто «собери», «протестируй», «задеплой». Чтобы не учить команды заново для каждого проекта, автор делает единообразные обёртки для типовых задач. Такие инструменты называют task runners.

Самый простой вариант — bash-скрипт в корне репозитория. В нём описываются функции install, build, test, format, а выбор команды делается через case. Скрипт можно назвать run, сделать исполняемым через chmod +x run — и потом работать как run build или run test. Внутри легко спрятать несколько шагов, например запуск юнит-тестов и Playwright одной командой. Bash есть почти везде, в том числе на CI/CD, но синтаксис у него так себе.

Второй вариант — make. Инструмент из 1970-х, но он до сих пор стоит у большинства разработчиков. Достаточно положить Makefile с целями install, build, test, format — и вызывать их как make test. make по умолчанию считает, что цель — это файл, который надо создать. Поэтому если рядом с Makefile появится файл с именем format, make откажется что-то делать и скажет 'format' is up to date. Чтобы этого избежать, цели объявляют через .PHONY. Приятный бонус: zsh и fish умеют автодополнять цели make почти из коробки, а для bash можно поставить пакет.

Третий — just. Он вдохновлён make, но убирает его странности вроде .PHONY. В корне проекта кладётся justfile с рецептами, и команды запускаются через just install, just test. Минус: just может не быть на машинах коллег, зато легко ставится через пакетные менеджеры.

Четвёртый — mise. За последние годы он превратился в швейцарский нож разработчика: умеет ставить пакеты, управлять версиями инструментов и переменными окружения, а ещё запускать задачи. В mise.toml задачи описываются секциями вроде [tasks.build] с полями description и run. Если файл разрастается, задачи можно выносить в отдельные файлы или оборачивать в маленькие bash-скрипты.

Итог простой: единообразные команды для рутинных задач — небольшое, но заметное улучшение. Настраивается за чашку кофе и при этом почему-то редко встречается в реальных проектах.

Читать оригинал →