Taskfile: Когда пора отказаться от Makefile (а когда — нет)

Введение

Makefile существует с 1976 года. За это время он стал стандартом де-факто для автоматизации задач в разработке: сборка, тесты, деплой, запуск окружения — всё это принято описывать через цели и зависимости. Его главное достоинство — простота модели и повсеместная доступность. Но именно эта простота оборачивается проблемой, когда проект перерастает рамки «выполнить команду, если изменился файл».

Taskfile, появившийся в 2017 году, предлагает иную модель: вместо shell-сценариев, обёрнутых в Make-синтаксис, — декларативная конфигурация на YAML, где сложные сценарии (кросс-платформенность, интерактивные запросы, условное выполнение) реализованы как встроенные механизмы, а не как самодельные конструкции.

Цель этой статьи — не доказать превосходство одного инструмента над другим, а показать, в каких случаях Taskfile действительно упрощает жизнь, а где Makefile остаётся более адекватным решением.

Документация и навигация

Первое, с чем сталкивается разработчик, заходя в проект, — попытка понять, какие задачи здесь вообще определены. В Makefile для этого традиционно создают цель help, которая с помощью grep и awk вытаскивает комментарии:

help:
    @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'

build: ## Собрать бинарный файл
    go build -o app ./cmd/...

Эта конструкция работает, но она кочует из проекта в проект как магическое заклинание, которое редко кто разбирает до конца. Она зависит от конкретного shell, требует аккуратного экранирования и ломается при малейшем отклонении от ожидаемого формата.

В Taskfile документация — встроенная возможность, а не обходной путь:

version: '3'

tasks:
  build:
    desc: Собрать бинарный файл
    cmds:
      - go build -o app ./cmd/...

Для проектов на Node.js, где задачи обычно разбросаны по полю scripts в package.json, Taskfile позволяет объединить документацию, установку зависимостей и контроль изменений в одном месте:

version: '3'

tasks:
  install:
    desc: Установить зависимости
    sources:
      - package.json
      - package-lock.json
    generates:
      - node_modules/.package-lock.json
    cmds:
      - npm ci

  dev:
    desc: Запустить режим разработки
    deps: [install]
    cmds:
      - npm run dev

  build:
    desc: Собрать production-версию
    deps: [install]
    cmds:
      - npm run build

Теперь разработчик видит все доступные команды через task --list, а npm ci выполняется только при реальных изменениях в package.json, экономя время при повторных запусках.

Команда task --list выводит все задачи с их описанием без дополнительных ухищрений. Документация становится обязательной частью конфигурации, а не опциональным комментарием, который могут удалить при рефакторинге.

Кросс-платформенность

Makefile исторически завязан на Unix. Поддержка Windows превращается в разрастающиеся условные конструкции:

SHELL := /bin/bash

ifeq ($(OS),Windows_NT)
    RM = cmd /c del /q
    SEP = \\
else
    RM = rm -f
    SEP = /
endif

clean:
    $(RM) build$(SEP)*

Этот код только кажется простым. При попытке поддержать Git Bash, WSL, PowerShell или отличия между rm на macOS и Linux условиям не будет конца. Makefile превращается в слой совместимости, который нужно отлаживать отдельно от основной логики.

Taskfile решает эту задачу на уровне архитектуры:

version: '3'

tasks:
  clean:
    platforms: [windows, linux, darwin]
    cmds:
      - rm -rf build/

Задача выполняется на всех платформах, но команда остаётся единой. Если нужно разное поведение в зависимости от ОС, используется поле platforms:

version: '3'

tasks:
  setup:
    platforms: [linux]
    cmds:
      - apt-get update
  setup:
    platforms: [darwin]
    cmds:
      - brew update

Taskfile сам определяет текущую платформу и выбирает подходящую версию задачи. Разработчик больше не пишет условия — он описывает варианты.

Контроль изменений (инкрементальные сборки)

Makefile умеет отслеживать изменения файлов и пересобирать цели только при необходимости. Но этот механизм завязан на временные метки и плохо масштабируется на сложные сценарии:

bundle.js: src/js/*.js
    esbuild --bundle --minify $^ > $@

Это работает, пока файлов немного и все они локальные. Если нужно отслеживать изменения в удалённых артефактах, проверять наличие файлов перед запуском или выполнять задачу только при изменении содержимого, а не времени модификации — приходится писать shell-скрипты.

Taskfile предлагает унифицированную модель:

version: '3'

tasks:
  build:
    sources:
      - src/js/**/*.js
      - package.json
    generates:
      - public/bundle.js
    method: checksum
    cmds:
      - esbuild --bundle --minify src/js/index.js > public/bundle.js

Поле sources описывает исходные файлы, generates — результат. По умолчанию Taskfile сравнивает хэши содержимого, но можно переключиться на timestamp или вообще отключить проверку. Кроме того, доступны программные проверки через status:

version: '3'

tasks:
  deploy:
    status:
      - test -f .env.production
    cmds:
      - ./deploy.sh

Задача выполнится только при наличии файла .env.production. В Makefile аналогичное поведение потребовало бы встраивания проверки в команду или использование условных конструкций на shell.

Интерактивность и валидация

В Makefile запросить подтверждение у пользователя или проверить наличие переменной окружения можно только через shell-код:

deploy:
    @if [ -z "$(ENV)" ]; then echo "ENV not set"; exit 1; fi
    @read -p "Deploy to $(ENV)? [y/N] " confirm; \
    if [ "$$confirm" != "y" ]; then exit 1; fi
    ./deploy.sh $(ENV)

Этот код зависит от bash, не работает в Windows без дополнительных прослоек и легко ломается при изменении синтаксиса. Более того, проверка переменной и запрос подтверждения оказываются внутри одной команды, что делает их сложными для отладки.

Taskfile выносит эти сценарии на уровень конфигурации:

version: '3'

tasks:
  deploy:
    requires:
      vars: [ENV]
    prompt: "Deploy to {{.ENV}}? (y/N)"
    cmds:
      - ./deploy.sh {{.ENV}}

Поле requires объявляет обязательные переменные — задача не запустится, если они не заданы. prompt выводит вопрос и ждёт подтверждения. Если в Taskfile включён интерактивный режим (interactive: true), недостающие переменные будут запрошены автоматически.

Этот подход удобен в сценариях, где важно предотвратить случайные действия в неправильном окружении. Например, запуск Docker Compose для разных сред:

version: '3'

tasks:
  up:
    desc: Запустить сервисы в указанном окружении
    requires:
      vars:
        - name: ENV
          enum: [dev, staging, prod]
    cmds:
      - docker-compose -f docker-compose.{{.ENV}}.yml up -d

  down:
    desc: Остановить все сервисы
    cmds:
      - docker-compose down

Аналогичный подход работает и для управления Kubernetes-контекстами, где случайное применение манифестов в неправильном кластере может привести к серьёзным последствиям:

version: '3'

tasks:
  switch-context:
    desc: Переключить контекст Kubernetes
    requires:
      vars:
        - name: CONTEXT
          enum: [dev, staging, prod]
    prompt: "Переключиться на {{.CONTEXT}}? Это повлияет на все последующие команды kubectl"
    cmds:
      - kubectl config use-context {{.CONTEXT}}

Разработчик, зашедший в проект, сразу видит доступные окружения через task --list, а попытка указать несуществующее окружение приводит к понятной ошибке с подсказкой допустимых значений.

Для переменных, принимающих ограниченный набор значений, можно использовать enum:

version: '3'

requires:
  vars:
    - name: ENV
      enum: [dev, staging, prod]

Модульность и переиспользование

Makefile позволяет подключать другие файлы через include, но все цели оказываются в одном пространстве имён:

include docker.mk
include k8s.mk

# Все цели из docker.mk и k8s.mk доступны напрямую
# Если в них есть цели с одинаковыми именами - конфликт

Это ограничивает возможность структурировать автоматизацию по доменам. В Taskfile подключение работает через неймспейсы:

version: '3'

includes:
  docker: ./taskfiles/docker.yml
  k8s: ./taskfiles/k8s.yml

Задачи вызываются с префиксом: task docker:build, task k8s:deploy. Конфликты имён исключены. При этом можно сделать включение «плоским» (flatten: true), чтобы задачи подключались без префикса, или опциональным (optional: true), чтобы отсутствие файла не прерывало выполнение.

Особенно полезной эта возможность становится при создании библиотек переиспользуемых задач. Один и тот же Taskfile можно подключить несколько раз с разными переменными:

version: '3'

includes:
  backend:
    taskfile: ./taskfiles/docker.yml
    vars:
      IMAGE: backend
  frontend:
    taskfile: ./taskfiles/docker.yml
    vars:
      IMAGE: frontend

Один файл описывает сборку Docker-образа, а в основном Taskfile он используется для двух разных компонентов с разными параметрами.

Итерации и работа с данными

Makefile не имеет встроенных конструкций для циклов. Если нужно выполнить команду для списка элементов, приходится либо дублировать цели, либо использовать shell-цикл:

SERVICES = api web worker

deploy-all:
    for s in $(SERVICES); do \
        ./deploy.sh $$s; \
    done

Этот подход возвращает к проблемам переносимости и смешивает декларативное описание с императивной логикой. В Taskfile итерации — часть синтаксиса:

version: '3'

tasks:
  deploy-all:
    vars:
      SERVICES: [api, web, worker]
    cmds:
      - for: { var: SERVICES }
        cmd: ./deploy.sh {{.ITEM}}

Для задач сборки, где требуется повторить одну операцию с разными параметрами, циклы становятся незаменимы. Например, сборка Docker-образов для нескольких платформ:

version: '3'

tasks:
  build:
    vars:
      PLATFORMS: [linux/amd64, linux/arm64]
      TAG: myapp:latest
    cmds:
      - for: { var: PLATFORMS }
        cmd: docker buildx build --platform {{.ITEM}} -t {{.TAG}}-{{.ITEM | replace "/" "-"}} .

Если же нужно перебрать все комбинации нескольких параметров, используется матрица. Это особенно полезно при кросс-компиляции или сборке образов для разных платформ с разными тегами:

version: '3'

tasks:
  build-matrix:
    cmds:
      - for:
          matrix:
            PLATFORM: [linux/amd64, linux/arm64]
            TAG: [latest, v1.0.0]
        cmd: docker buildx build --platform {{.ITEM.PLATFORM}} -t myapp:{{.ITEM.TAG}}-{{.ITEM.PLATFORM | replace "/" "-"}} .

Одна конфигурация порождает четыре варианта сборки, и каждый запускается с правильными параметрами.

Ещё один сценарий, где Taskfile показывает свои возможности, — управление временными ресурсами. В Makefile гарантированная очистка даже при ошибке требует сложных trap-конструкций на shell. Taskfile предоставляет встроенный механизм defer:

version: '3'

tasks:
  test-database:
    desc: Запустить тесты с временным контейнером PostgreSQL
    cmds:
      - docker run -d --name test-postgres -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:15
      - defer: docker rm -f test-postgres
      - sleep 5
      - DATABASE_URL=postgres://postgres:test@localhost:5432/postgres npm run test:migration
      - npm test

defer гарантирует, что контейнер будет удалён даже при падении тестов или миграций. В Makefile аналогичное поведение потребовало бы обёртки всей команды в shell-функцию с trap.

Механизм defer — ещё один пример того, как Taskfile берёт на себя сложность, которая в Makefile требует изобретательности.

Важно, что Taskfile поддерживает не только строки, но и структурированные данные. Переменные могут быть массивами или картами, и их можно передавать между задачами по ссылке, сохраняя тип:

version: '3'

tasks:
  prepare:
    vars:
      CONFIG:
        map: { host: localhost, port: 8080 }
    cmds:
      - task: start
        vars:
          CONFIG:
            ref: .CONFIG
  start:
    cmds:
      - ./start.sh --host {{.CONFIG.host}} --port {{.CONFIG.port}}

Это позволяет строить сложные конвейеры обработки данных, оставаясь в рамках декларативного описания.

Когда Makefile остаётся лучшим выбором

Taskfile удобен, но у него есть ограничения, которые в определённых сценариях делают Makefile предпочтительнее.

Доступность без установки. Makefile есть в любой Unix-подобной системе. Если вы пишете инструмент, который должен работать в минимальных окружениях (базовый Docker-образ, встраиваемые системы, восстановление после сбоев), Makefile будет работать без дополнительных шагов. Taskfile требует установки — одной команды, но в изолированных средах это может быть проблемой.

Производительность на очень больших графах. Makefile десятилетиями оптимизировался для сборки проектов с тысячами файлов (ядро Linux, крупные C++ проекты). Его алгоритм отслеживания зависимостей выверен до предела. Taskfile использует другой подход (по умолчанию — хэши содержимого), который для подавляющего большинства проектов работает быстрее и надёжнее, но на экстремальных масштабах поведение может отличаться.

Полный контроль над shell. Taskfile использует mvdan/sh — реализацию shell на Go, обеспечивающую кросс-платформенность. В 99% случаев этого достаточно. Но если вам нужны специфические возможности конкретного shell (расширения zsh, особенности bash 5.x, прямое взаимодействие с системными вызовами), Makefile, который просто передаёт команды нативному shell, даст больше гибкости.

Накопленный опыт. Makefile знают практически все разработчики. Существуют миллионы примеров, проверенных решений для типовых задач. Taskfile моложе, и не для всех сценариев уже сложились устоявшиеся паттерны. Для команды, где все участники бегло владеют Makefile и shell, переход на Taskfile может не дать ощутимого выигрыша, но потребует времени на освоение.

Стратегия внедрения

Переход на Taskfile не требует резкого отказа от Makefile. Возможны три стратегии, различающиеся по степени вовлечённости.

Новый проект. Самый простой способ — начать с task --init и сразу строить автоматизацию на Taskfile. Команда task --list даёт документацию из коробки, а структура конфигурации остаётся чистой, без наслоений десятилетий эволюции.

Гибридный подход. Makefile остаётся главной точкой входа, но вызывает Taskfile для сложных сценариев:

# Makefile
task:
    task $(ARGS)

deploy:
    task deploy

.PHONY: task deploy

Разработчики, не перешедшие на Taskfile, продолжают использовать make deploy. Те, кто готов пробовать, могут вызывать task deploy напрямую. Постепенно сложная логика мигрирует в Taskfile, в Makefile остаются только простые цели-прокси.

Рефакторинг проблемных мест. Вместо тотальной замены можно перенести одну задачу, которая всегда вызывала сложности: кросс-платформенную установку зависимостей, деплой с проверками, сборку с матрицей параметров. После того как команда оценит разницу, область использования Taskfile расширяется естественным образом.

Ключевой принцип всех трёх стратегий — постепенность. Taskfile и Makefile могут сосуществовать сколь угодно долго, и нет необходимости в «большом переезде».

Часто задаваемые вопросы

curl -1sLf 'https://dl.cloudsmith.io/public/task/task/setup.deb.sh' | sudo -E bash
sudo apt install task

Заключение

Выбор между Makefile и Taskfile редко сводится к объективному превосходству одного инструмента. Это вопрос о том, на что вы готовы тратить свою когнитивную нагрузку.

Makefile оставляет разработчика один на один с shell-скриптами, платформенными различиями и самодельными решениями для документации. Зато он есть везде, его знают все, и он проверен десятилетиями на проектах любого масштаба.

Taskfile берёт на себя сложность, изолируя от платформенных деталей и предоставляя встроенные механизмы для сценариев, которые в Makefile требуют изобретательности. Он требует установки и привыкания к YAML-синтаксису, но взамен даёт читаемую, самодокументируемую конфигурацию, которая масштабируется вместе со сложностью проекта.

Ни один из вариантов не является неправильным. Правильный — тот, который осознанно выбран под конкретный проект, команду и контекст.

Taskfile доступен через большинство пакетных менеджеров: brew install go-task/tap/go-task на macOS, apt install task на Debian-системах, winget install Task.Task на Windows либо через универсальный скрипт, описанный в официальной документации. Детально процесс установки описан в разделе Installation официальной документации. Попробуйте перенести одну из существующих Makefile-целей — ту, которая всегда казалась слишком сложной. Сравните не количество строк, а то, сколько времени ушло на отладку и насколько понятна конфигурация через месяц. Этот эксперимент даст больше понимания, чем любое теоретическое сравнение.