Важный этап: Переход на Go и Внедрение Task нативно

[dealenx]

Раньше razd был умной оберткой, которая требовала наличия установленного task (Taskfile) в системе. Это создавало лишний барьер для входа: "скачай razd, а, ой, еще task установи".

Я решил это изменить.

Мы избавляемся от exec.Command("task", ...) и жесткой зависимости от бинарника. Теперь движок Go-Task (v3) импортируется как библиотека прямо в код razd.

Что это дает?
✅ Zero Dependency: Пользователю нужен только один бинарник razd. Всё работает из коробки.
✅ Контроль: Прямой доступ к API раннера (stdout/stderr стриминг, контексты, хуки) вместо парсинга текста из консоли.
✅ Скорость: Нет накладных расходов на спаун новых процессов ОС.

Теперь razd - это не просто CLI-враппер, а самодостаточный инструмент для инициализации и управления проектами, с мощью Taskfile под капотом.

План миграции и технический дизайн уже готовы. Ссылка на PR/Issue внизу 👇

#golang #opensource #devops #razd #taskfile

---

2. Технический дизайн (RFC / Design Doc)

Этот документ можно прикрепить к Issue на GitHub или положить в документацию для контрибьюторов.

---

RFC: Native Taskfile Runner Integration

1. Context & Problem

В текущей реализации razd полагается на внешний бинарный файл task, вызывая его через os/exec.
Проблемы:

• Зависимость среды: У пользователя должен быть установлен task в $PATH.
• Хрупкость: Парсинг вывода ошибок и статусов выполнения через stdout/stderr ненадежен.
• Ограниченный контроль: Невозможно гибко управлять контекстом выполнения или перехватывать внутренние события раннера.

2. Solution

Интегрировать пакет github.com/go-task/task/v3 непосредственно в кодовую базу razd. Использовать task.Executor для программного запуска задач вместо spawning subprocesses.

3. Architecture Changes

Current Flow (Legacy)

flowchart LR
    A[Razd CLI] --> B(fork/exec)
    B --> C[Task Binary]
    C --> D[Taskfile.yml]

Loading

Target Flow (Native)

flowchart LR
    A[Razd CLI] --> B[Task Library Embedded]
    B --> C[Taskfile.yml]

Loading

4. Implementation Details

Dependency

Добавление зависимости в go.mod:

go get github.com/go-task/task/v3

Code Reference

Вместо вызова командной строки, мы инициализируем Executor.

import (
    "context"
    "github.com/go-task/task/v3"
    "github.com/go-task/task/v3/args"
)

type NativeRunner struct {
    // конфигурация
}

func (r *NativeRunner) Run(ctx context.Context, taskName string) error {
    e := task.Executor{
        Dir:        r.WorkDir,
        Entrypoint: "Taskfile.yml",
        
        // Прямой проброс потоков для интерактивности
        Stdin:  os.Stdin,
        Stdout: os.Stdout,
        Stderr: os.Stderr,
        
        // Опционально: переопределение цветов или переменных
        Color:  true,
    }

    // Инициализация (парсинг yaml, env vars)
    if err := e.Setup(); err != nil {
        return fmt.Errorf("failed to parse Taskfile: %w", err)
    }

    // Выполнение
    return e.RunTask(ctx, &args.Call{Task: taskName})
}

5. Constraints & Risks

• Internal Packages: Go-Task скрывает логику парсинга YAML в пакете internal/taskfile. Мы не можем модифицировать структуру Taskfile программно до запуска, только исполнять существующие файлы. Это приемлемо для razd, так как мы генерируем файлы на этапе init.
• Binary Size: Размер бинарника razd увеличится (~ +2-3MB), так как код Taskfile теперь включен в сборку. Решается через go build -ldflags="-s -w".

6. Benefit

Превращает razd в standalone tool. Пользователь скачивает один бинарник и получает полностью настроенное окружение для работы с проектом.

[dealenx]

https://github.com/razd-cli/razd/tree/v1-go-rewrite