boilerplateとscaffoldingとそんな感じのあれこれ
明けましておめでとうございます。
2026年、また少し落ちていたアウトプットを少しばかり取り戻そうと思う新年です。
さて、では記事を書こうにも、アウトプットにはインプットや試行錯誤が必要で、当然それらも欠落している今の私です。
アイデアという名の免罪符の元に、徒然と駄文を刻むより他にないのでこのような記事になりました。
ハマりやすい性格とboilerplate/scaffoding
今まで色々つまらないものを作ってきました。
GoにハマればGo開発の関連ツール、VimにハマればVimプラグイン。
いずれにせよ、特定のパターンにハマって些末なものを繰り返し作っていると、やがて「いつもこの手のプロジェクトを作るときに似たようなものを書かされているな」と思い至ります。
すると私は悪癖としてパターン化されたモノを特定の型にはめてメンテナンスを楽にしたいと思うのです。
読者の皆さんもそうかもしれませんし、そうではないかもしれません。
記事だけでもこんな感じの記事を書いてますね。
- https://zenn.dev/kyoh86/articles/qiita-74dbf9dcddd5bd43e01e
- https://zenn.dev/kyoh86/articles/5e7fe8c16a39aa3d3796
リポジトリにもテンプレ的なリポジトリを用意しています。
自作のghqモドキのプロジェクト管理ツールも、boilerplate/scaffolding的なことをできる機能を有しています。
- https://github.com/kyoh86/gogh/blob/main/doc/usage/gogh_extra.md
- https://github.com/kyoh86/gogh/blob/main/doc/usage/gogh_hook.md
過去にはYeomanようのテンプレートを作っていたこともありました。
どんだけ好きなんでしょ。
boilerplateくんさあ…
ところで、こういうboildrplate/scaffoldingを用意することで楽できないポイントとして、利用したプロジェクトのアップデートが面倒くさいというのがありますね。
boilerplateから生成したプロジェクトは、当然abstractなboilerplateから見ればconcreteな代物で手に負えません。
例えば、私が作っているdenops-boilerplate.vimは以下の様な構成になっています。
- 動機:
deno lintの対象をプロジェクトによって限定したい、しかしCIはプロジェクト横断で同じにしたい - 解決:
deno.jsoncで"tasks"に"lint"を用意して、"deno run lint <対象のファイル群>"を明記させよう- → CIはすべて
deno task lintを一律呼べばいい!
- → CIはすべて
- 問題:現在はdeno.jsoncで
deno lintの対象を指定する方法が提供されている- →
denos.jsoncで"lint"に"include": ["./**/*.ts"]のように指定すれば良い - → これさえ用意しておけばCIはすべて
deno lintを画一的に呼べば良い
- →
Deno側のサポートの増強により、私の解決策は古いものとなってしまいました。
しかし、これを更新しようとすると、denops-boilerplate.vimを元に作ったプロジェクト達も同じように更新しなくてはなりません
- ddu-filter-converter_hl_dir
- ddu-source-command
- ddu-source-docbase
- ddu-source-git_branch
- ddu-source-git_diff_tree
- ddu-source-git_log
- ddu-source-github
- ddu-source-gogh
- ddu-source-lazy_nvim
- ddu-source-local_ddu
- ddu-source-quickfix_history
- ddu-source-zenn_dev
- denops-bind-params
- denops-boilerplate.vim
- denops-docbase.vim
- denops-github.vim
- denops-qftable.vim
- denops-router
- denops-util
- denops-zenn_dev.vim
- denops-zshist.vim
面倒くさいです。
こんなんほしいよね
これ、boilerplate側をバージョン管理して、生成物もバージョン管理されてるんですから、生成物とboilerplateの差分管理で上手いこと一括適用できる仕組みがあれば良いんですけどね。
要は生成だけじゃなく、applyしたいんです。
しかし、boilerplateからみれば生成物はもはやあずかり知らぬ物ですから、生成物側にも独自のdiffも生じているでしょう。
そこら辺は上手いことconflictしたものとして人間なりAIに解決させてくれれば、良い感じに扱えそうです。
色々アイディアをこねくり回せば、何か超良い感じのboilerplate engine(とはもはや言えない何か)が作れそうではないですか。
とはいえ何となく、仮に実現されたとしても使い勝手がとても悪そうだなと思っています。
多分これを実現できてるツールは、その学習コストがとんでもなく高いでしょう。
気軽に使おうと思ったら、使いこなすには概念から理解が必要なヤツだ!となるgitのようなプロダクトの予感がします。
まあ、あまり期待していません。
終わりに
新年一発目には実に相応しくない駄文でお目汚し失礼しました。
世の中にそんな行けてるステキな何かがあったら教えてください。
Discussion