MarkdownベースのGo製タスクランナー「xc」のススメ

Goにおけるタスクランナーの歴史 npmならnpm run、denoならdeno taskなど言語ツールにタスクランナー機能が付属していることがありますが、Goではそのような機能は提供されていません。 そこでGoのプロジェクトではMakefileがタスクランナーとして用いられることがしばしばありますが、独自の文法、.PHONYを大量に書く必要がある、Makefile警察が飛んでくる、などの問題があります。 Makefile警察「ぐぬぬぬ…」 #taskfile - Qiita タスクランナーとしてMakefileを使うことから脱却すべく、巷ではYAMLベースの「Task」やGoベースの「Mage」が用いられている印象です。 どちらも多少試したことはありますが、主に以下の点が気になりました。 Taskfile.ymlやmagefile.goといったツール独自のファイルを置く必要がある これは

[tmatsuu]

README.mdに各タスクのコマンドを記述、xcはそのREADME.mdに記述されたタスクを実行できる。おー目から鱗だ。面白いなそれ。最高では。

[xKxAxKx]

きになる

[a-know]

良さそう

[snowcrush]

makeでええやん。というか今もmakeが主流という認識。Go本体に組み込まれるならともかく3rd partyだと乗り換える意味ないと思う。一定数嫌いな人がいるのは分かるので個人プロジェクトなら好きにすればいいとも思うけど。

[diveintounlimit]

“GoのプロジェクトではMakefileがタスクランナーとして用いられることがしばしばあります”まだこのへんのエコシステム整ってないねんなぁという所感。

[xlc]

そもそもrpm-scriptは単なる「エイリアス」であり「タスクランナー」ではなかろう。コンパイルに時間がかかった時代はMakefileのような部分実行が時間短縮に貢献したが、今は「全やり直し」で問題ないので廃れたのよ。

[yojik]

文芸的プログラミング的な

[big_and_small]

正直「文芸的プログラミング」のリバイバルにしか見えない。「文芸的プログラミング」が1984年なんで、ここ40年ほどずっと同じような所を行っては来てを繰り返してる

[yarumato]

“npmならnpm run、denoならdeno taskなど言語ツールにタスクランナー機能が付属。Goではその機能は未提供。タスクランナーとしてMakefileから脱却したい。Markdown内のコマンドを実行するツールはGoogleのTypeScript製「zx」が有名”

[bopperjp]

複数の意味を持つドキュメントとかぜったい崩壊する。「え、ここってコードだったの？」とか。そんなのイヤ。Makefile (というか GNU Make)サイコー。

[tacamula]

コードにコメントを書くのの逆転で、ドキュメントにコードを添付できる発想は面白い。zx使ってるので自分は乗り換えないかもしれないが、広まるのはいい

[honeybe]

ちょっと発想がおもしろい。後で。

[progrhyme]

README.md にタスクを書いてそのまま実行できると

[pullphone]

良さそう

[wwolf]

何故人々はdevcontainerを使わずローカルに環境を構築してしまうのか

[red_kawa5373]

Markdownでタスクランナー？　と思ったが、確かにこの方法だとマニュアルとタスクランナーを同居させられるな。