タスクランナー Task の話をしよう

tl;dr

• go-task/task: A task runner / simpler Make alternative written in Go
• GNU Make の代替ツール Task の話をしよう

task

• Go で書かれた GNU Make の代替になるタスクランナー、ビルドツール
• シンプルさと簡単さを売りにしている（らしい）
• Initial commit は 2017-02-27 みたい
• YAML 形式の設定ファイルで指定の処理を実行する（ビルドでもタスクでもコマンドラインな処理を呼べる）
• Windows も（制限はあるけど）サポートしている

ADR向け

提案

• 複雑化、専業化するタスクやビルドを統一して扱えるラッパーが欲しい
• タスクランナー、ビルド、作業手順書の代替

メリット

• 処理、作業のコード化
• 統一化
• オンボーディングが楽
• 自動化が簡潔

デメリット

• タスクを作成する手間（すでに独自の手順を確立しているとか）
• 冗長（に見えるケースがあるのは否めない）
• 自由度が減る（各自が異なるツールで作業しているなど）

タスクランナーとして

• ローカルでの繰り返し作業の簡便化
• 処理内容の共有

ビルドツールとして

• ビルド手順のラッピングと共有
• 手順のコード化による手順書の代替

比較

• Make - GNU Project - Free Software Foundation
• suzuki-shunsuke/cmdx: Task runner. It provides useful help messages and supports interactive prompts and validation of arguments
• jdx/mise: dev tools, env vars, task runner
• 他にいいのがあったら教えてください
• モダンなタスクランナーを求めて task (taskfile.dev) を使うまでの軌跡で他のツールや選定について書きました

詳細と議論

• 要不要はチームや組織によって異なる
• 統一化はとくに反発が予想される
• 正しくディベートできないとADRって難しいよね

個人的に思ってること

• フロントエンドのツールってたくさんあるし、それぞれのお作法覚えるの面倒だよね
• バックエンドのビルドもたくさん（以下略
• デプロイやリリースを作るの（略
• ラッピングしたツールで専業外の人でも同じ操作で同じ結果を生むことができると楽だよね
• HashiCorp WayPoint はそういうところ目指してたはず
• 転職等で所属が変わると使用しているツールも変わる
• ラッピングされた統一ツールを使っていると少なからずオンボーディングが楽になる（かも）

非難する意図はないけど、Task 以外のツールの面倒だなって思うところ

• 独自の記法が多い
• ルールが自由すぎる
• ツール自体がコマンドラッパー
• 導入に特定の言語が必要だったりライブラリ管理が必要だったり
• デファクトスタンダードな他ツールとの親和性
• 最近は周囲で mise がじわじわ来てるんだけど、タスクを書くのが toml なの
• mise task のファイル分割管理可能なところと XDG_BASE なディレクトリに配置できるところは高評価なんだけれども

• ツールの選定にあたっては、一家言持ちが強いのは当然
• やりたいやりたくないや、できるできないをなるべく多く押さえておく必要がある
• まだまだ Task でできるできないを整理しきれていないので、もっと日本語の情報が集まるといいなって
• というわけで task runner go-task(taskefile.dev) の話をしよう - Qiita Advent Calendar 2024 - Qiita を誰か書きませんか？