kickstart.nvim から LazyVim へ乗り換えた
半年前、 Neovim をカスタマイズして IDE に近づけるという記事を書いた。このとき設定テンプレートとして、いくつかの候補の中から kickstart.nvim を選択した。しかし最近、そのとき候補の1つであった LazyVim に乗り換えた。今回の記事では、 kickstart.nvim から LazyVim に乗り換えた理由、乗り換えの手順などについて記す。
環境
- macOS (x86_64) Sonoma 14.5
- Neovim 0.10.2
- LazyVim v12.44.0
kickstart.nvim からの乗り換えを決めた理由
最初に注意しておくと、 LazyVim を引き合いに出して kickstart.nvim を貶めるような意図はまったくない。 kickstart.nvim は Neovim を使い慣れてきた人がカスタマイズに入門する敷居を大きく下げる素晴らしいプロジェクトだと思う。
乗り換えを決めたのは、 kickstart.nvim より LazyVim の方が今の自分の Neovim に対するスタンスに合っていると考えたからだ。特に Neovim のカスタマイズコストが軽減されることが理由として大きい。
プログラミングに対する意識の変化
ツールやエコシステムが進化するにつれて、自身でプログラミングをする機会はどんどん少なくなってきたように思う。自分がプログラマーを目指したきっかけの1つは、まさに Vim のプログラミング体験に魅入られたことだ。学生時代に物理の数値計算のコードを Vim で書いているうちに、物理よりもプログラミングの方が楽しくなって Web 開発の業界に就職した。ソフトウェア開発の実務に取り組み始めると、次第に Vim の出番は減っていき、 VS Code や JetBrains などの IDE を使用することが増えた。最近では ChatGPT を利用できるようになり、自分で書くコードの量も減りつつある。
エコシステムが変化するにつれて、ソフトウェアの開発効率に関する自分の見方も変化してきたように感じる。以前は自身の力でコードを書かなければならない場面が多く、 Vim のキーバインドやテキストオブジェクトなどの機能を通して獲得できるようなミクロなレベルの効率性も重要だと考えていた。しかし、最近ではツールの力によってコードを半自動的に作成できるようになり、エディタの重要性をあまり感じなくなってきた。その代わりに設計やアーキテクチャ、フロー効率など、よりマクロなレベルの効率性へと興味がシフトしつつある。
結果的に Neovim のメンテナンスの優先度は下がり、コストをあまり掛けるべきではないと考えるようになった。最初に kickstart.nvim を導入した時、この観点を過小評価していたように思う。
なぜ kickstart.nvim を使うのを止めたのか
kickstart.nvim の目的は "a starting point for your configuration." を提供することだ ^1 。誤解を恐れずに言うと、これから Neovim をゴリゴリとカスタマイズしたい人にとって最適なスタート地点あり、導入後に一定のメンテナンスコストが掛かることは織り込み済みなのだ。逆に言うと、そのようなメンテナンスコストを払えないのであれば kickstart.nvim は向いていないと言えるかもしれない。
実際に導入してみて、 kickstart.nvim のメンテナンスコストはそこそこ高かったように感じている。具体的には親元のリポジトリの更新に追従するコストが高かった。
kickstart.nvim では本体のリポジトリをフォークし、それをクローンして利用することが推奨されている。この方法のメリットは、フォークした自分のリポジトリを親元のリポジトリに追従させることで、親元リポジトリで行われた各プラグインの破壊的変更への対応などを取り込めることだ。自分もこの方法で kickstart.nvim を導入した。
しかしこの方法には、親元のリポジトリに追従する際にコンフリクトが起こりやすいというデメリットもあった。利用者のリポジトリは各自の好みや都合に合わせてカスタマイズされていく。親元のリポジトリは随時更新されているが、その更新箇所とカスタマイズした箇所が重なっていた場合、コンフリクトが起こる可能性がある。実際、ここ半年で何度かコンフリクトを起こしている。
このままカスタマイズを進めていくと、コンフリクトが起こる頻度はより高くなるのだろうと予想している。基本的に自分のリポジトリの変更は属人的である。親元にとって都合の良い変更ではないため、変更を親元にフィードバックすることはない。カスタマイズが進むにつれてリポジトリの内容は徐々に乖離し、コンフリクトが起こる可能性は高くなっていく。
では自分のリポジトリを変更しないようにすれば良いのでは、とも考えたが、それはいくつかの理由で難しかった。まず、使い慣れた設定や各プログラミング言語の LSP プラグインの追加など、個別最適のための変更を完全には避けられない。また、 Telescope のファイル検索における隠しファイルの扱いなど、 kickstart.nvim のデフォルト設定が自分に合わずに修正したくなる場合もある。
kickstart.nvim の導入時点で多少のコンフリクトが発生するのは想定済みではあったが、前述したメンテナンスコストについての考えを自覚したため、 kickstart.nvim から離れることにした。
なぜ LazyVim を使い始めたのか
そして Neovim ディストリビューションを探し始めた。
Vim から手を引く話の流れじゃないのかという感じだが、 Vim 自体はどうしても断捨離できなかった。 vim コマンドを実行すると VS Code が起動するようにエイリアスを張り替えるという荒技も試したが、すぐに耐えられなくなって止めた。学生時代から触ってきた Vim はもはや自分の一部であり、そんなに簡単に切り離せるものではなかった。
ディストリビューションを利用せずにバニラで使うという手もあるが、それも考えづらかった。 kickstart.nvim を導入した際に過去の設定をほぼすべて捨て去っており ^2 、それらを復活させるとなるとメンテナンスコストはむしろ増加してしまう。一方で Neovim ディストリビューションはその本体がプラグインの形式で提供されているものが多いため、 kickstart.nvim よりもコンフリクトが発生しづらそうだという点が魅力的だった。
最終的に kickstart.nvim の導入検討時から候補に上がっていた LazyVim を導入することにした。似たようなディストリビューションの NvChad とも悩んだが、 LazyVim の方がメンテナンスコストが低く済みそうだと判断した。いずれのディストリビューションでも、本体とは別にある starter リポジトリ をクローンして利用するのが流儀だ。2つの starter リポジトリを見比べてみて、 LazyVim の方がコンフリクトの発生リスクが小さいように見えた。
Neovim 設定ファイルの変更
続いて Neovim の設定ファイルの変更手順を記す。自分の場合、 dotfiles リポジトリ の特定のディレクトリに kickstart.nvim リポジトリをサブモジュールとして紐づけて管理していた。この紐付けを解除し、新たに LazyVim の starter リポジトリを紐づける。
まず、 dotfiles から kickstart.nvim のサブモジュール化を解除する。 dotfiles リポジトリ上で次の操作を行う。
git rm config/nvim
rm -rf .git/modules/config/nvim
git config --remove-section submodule.config/nvim
次に LazyVim をインストールする。 LazyVim のインストール手順には starter リポジトリを ~/.config/nvim にクローンすべしと書いてあるが、自分の場合は kickstart.nvim と同様にフォークすることにした。今まで通り設定ファイルの変更履歴を管理したいからだ。
starter リポジトリをフォークしたら、それを dotfiles にサブモジュールとして取り込む。 starter リポジトリの名前は分かりやすいように少し変更している。
git submodule add [email protected]:hamakou108/lazyvim-starter.git config/nvim
Neovim の設定に反映させるため、 ~/.config/nvim に dotfiles の config/nvim へのシンボリックリンクを貼る。自分の dotfiles にはシンボリックリンクを貼るためのシェルスクリプトがあるので、それを実行する。
sh bin/link.sh
Neovim を起動した時、 LazyVim のスタートアップ画面が表示されることを確認する。
起動後に lazy-lock.json と lazyvim.json というファイルが生成される。 lazy-lock.json は LazyVim で利用されているプラグインマネージャーの lazy.nvim が生成するロックファイルだ ^3 。これはバージョン固定のためにリポジトリ管理に含めておく。 lazyvim.json は LazyVim によって生成されるファイルで、実体はよく分からないが、無視しても特に問題のないものらしい ^4 。
終わりに
自分は Vim のことになると悩みあぐねる悪癖がある。特にこの半年は酷く、 kickstart.nvim のままカスタマイズを頑張ろうとしたり、 VS Code に完全移行して VSCode Neovim を導入しようとしたりと、色々なことを試してはハマらない感じで迷走していた。 LazyVim を導入してようやくひと段落ついたが、この悪癖が治まってメインの開発に集中できるようになることを願うばかりだ。