Neovim Pack

 (neovim.io)
1 ポイント 投稿者 GN⁺ 2025-09-06 | 1件のコメント | WhatsAppで共有
  • Neovim は実験的な組み込みプラグインマネージャー vim.pack を導入し、外部マネージャーなしでプラグインのインストール・バージョン管理・削除機能を統合して提供
  • （初期テスト段階のため、API は頻繁に変更される可能性あり）

主な特徴

  • $XDG_DATA_HOME/nvim/site/pack/core/opt ディレクトリ専用で管理
  • プラグインは必ず Git リポジトリ形式である必要があり、git コマンド（最低 2.36 以上）が必須
  • プラグインのバージョンは semver タグ（v1.2.3 形式）やブランチ/コミットハッシュなどで指定可能
  • インストール、更新、削除、バージョン固定（freeze）などすべての操作を組み込み関数で処理

インストールおよび更新の動作方式

  1. vim.pack.add() を init.lua に追加（複数形式をサポート）
  2. Neovim 再起動時に自動でインストールを実行
  3. vim.pack.update() 呼び出し時に最新バージョンへ一括更新可能
  • 更新チェック、プレビュー（LSP ベース）、コンソールでの確認/キャンセルをサポート
  1. バージョン変更時は、init.lua 内のバージョン指定を修正した後、vim.pack.update({ 'プラグイン名' }) を実行
  2. バージョン freeze は現在のコミットハッシュ基準で指定
  3. 削除は vim.pack.del() の呼び出しで処理

API の主なパラメータと動作

  • add: プラグイン一覧を受け取り、存在しなければ git clone でダウンロードし version をチェックアウト
  • 更新: force フラグで即時/確認ダイアログモードを選択可能、変更履歴は "nvim-pack.log" に残る
  • 各イベント（インストール/更新/削除）時に hook を提供し、プラグインのメタ情報を公開

参考事項

  • 本番環境では実験的マネージャーのため、突然動作が変更される可能性あり
  • すでにディスク上にプラグインがあっても、実際のバージョンと指定バージョンが一致しない場合があるため、update による同期が必須
  • 削除時は add から仕様を削除しないと再インストールを防げない

関連記事

  • Neovim 0.12.0
    2 ポイント · 1件のコメント · 2026-03-30

1件のコメント

 
GN⁺ 2025-09-06
Hacker News のコメント

  • 今回のアップデートをかなり楽しみにしている。nvim プラグインコミュニティが、複雑なプラグインマネージャである lazy を使わずに、標準でプラグインを lazy loading できる方向に発展してほしい。nvim の公式ドキュメントにも関連ノートがあるので参考にしてほしい: nvim lazy loading 公式ドキュメント。個人的には nvim-neorocks プラグインが提案している best practices もとても良いと思う: nvim-neorocks best practices。最近、その一部が公式にマージされたようだ: neovim PR #29073

    • neovim で setup() モデルを使うようになったことで、lazy loading は従来の Vim のやり方より少し厄介になったと感じる。Vim では変数を設定しておけば、関数が実行されるときに自動でプラグインが読み込まれた。Lua ベースでは、複数の autocmd が同じプラグインを参照する場合、どれも setup() を明示的に呼ぶ必要があり、少しオーケストレーションが増える

  • (Neo)Vim のパッケージマネージャはだいたい 3 年ごとに乗り換えている気がする。自分の遍歴は pathogen → Vundle → vim-plug → lazy.nvim という順番だった。これが最後の Vim パッケージマネージャになってほしい

    • Plug もまだ十分使えると思う。今回の内蔵版は言語自体に組み込まれているので、より多くのユーザーにとって満足できる終着点になりそうだ。実際に使ってみたが、lazy が提供していた特別な機能は使っていなかったこともあり、普通に問題なく動いた

    • ついに公式に組み込まれた公式パッケージマネージャになったのがうれしい。今後いちばん広くサポートされ、使われる可能性が高いと思う（もちろん機能の豊富さは別かもしれないが）

    • lazy.nvim も非常に強力だと思う。ただ、いろいろなプラグインがそれぞれ多様なパッケージマネージャをサポートしているので、ある程度の統一性も必要だと思う。lazy.nvim ほど高速で信頼感のあるものが作れるかは疑問だが、不可能ではない気がする

    • 自分は nixvim を使い始めた。vim-plug のころにもう諦めていた。複数のマシンとさまざまな OS で設定を常にうまく保つのがつらかった

    • Nix ならいつでも同じやり方で動く。NixOS、MacOS、Linux の nix-managed home-manager で次のように設定できる

      neovim = {
  enable = true;
  vimAlias = true;
  vimdiffAlias = true;
  defaultEditor = true;
  plugins = [
    pkgs.vimPlugins.fugitive
    pkgs.vimPlugins.fzf-vim
    pkgs.vimPlugins.vim-gh-line
    pkgs.vimPlugins.vim-gutentags
    pkgs.vimPlugins.nvim-lspconfig
    pkgs.pkgs-unstable.vimPlugins.vim-go
    pkgs.pkgs-unstable.vimPlugins.zig-vim
  ];
  extraConfig = builtins.readFile ./vimrc;
  extraLuaConfig = builtins.readFile (pkgs.replaceVars ./dev.lua {
    inherit (pkgs) ripgrep;
  }).outPath;
}

  • neovim ユーザーの助けになればと思い、最近 lazy.nvim から vim.pack だけを使う形へ移行した: この Pull Request を参照。問題はまったくなく、使っているプラグインは 50 個ほど。予想よりずっと簡単で、知人の助けもあって lazy と似た形でプラグインが読み込まれる設定を作れた。特に仕事用の PC では、lazy.nvim で 300ms かかっていたプラグイン読み込みが、今では 80ms まで減った

    • ちなみにそのリンクは diff 内の無関係なファイルを指している

  • git からコードを import できて、ブランチやコミットハッシュまで指定できる機能を見るたびに、「ある時点のブランチを checkout する」機能の文書化を望んでしまう。多くの Vim プラグインのブランチはバージョン管理すらされていないことがある。たとえば git checkout 'master@{2025-05-26 18:30:00}' のように、特定の日時に合わせて checkout できる。leftPad 騒動や xz セキュリティ事故のような、バージョン管理の失敗を防げたらという思いがある

    • 面白いアイデアには聞こえるが、「どの時計の時点を基準にするのか？」という疑問がある。リポジトリ自体の時計なのか、自分の PC の時計なのか、それともリモート git の時計なのかが重要だ。普通はハッシュを使うべきで、時間ベースのソフトウェア開発はおすすめしない（最後の手段でない限り）

    • サプライチェーン攻撃に対するリスクが気になる。VIM プラグインがどの程度の権限を持つのか知りたい

    • 指定時点の master を checkout すると、その時点のものを取ってくるのではなく、自分が pull した時点基準になってしまって混乱する（再現性がない）。本当の再現性が欲しいなら、git log --before=time などでもっと複雑な方法が必要になる

    • 単に SHA を使えばいいのでは？

  • Vim のプラグインマネージャは必須ではない。特に dotfiles を git で管理しているならなおさらだ。プラグインのファイルを指定ディレクトリに clone するだけでいい。設定も git で管理すれば、git submodules でプラグインのバージョンを固定して追跡できる。この方法はバージョン pinning にも向いている

    • 自分も 1 年間 git submodule を使っていた。あらゆるツール専用のパッケージマネージャを submodule に置き換えられるのでは、という考えが動機だった（vim、tmux、zsh など）。ただ実際には、submodule の管理は vim-plug に比べてかなり面倒だった。考え方としては良いが、Git での ergonomics が低い。結局また戻ってしまった。内蔵の vim pack を使って vim-plug よりも楽だったという体験談があれば共有してほしい

    • 自分はプラグインを頻繁に有効化・無効化したいので、単純なファイルシステムより config で扱うほうが楽だ。そしてファイルタイプごとにプラグインを有効化しやすい。実際、ほとんどのプラグインマネージャは結局 git のラッパーにすぎないと思う

  • まだかなり原始的な状態だと思う。ただ、いつか lazy をやめる日が来るなら deferred load は実装されていてほしい。lazy.nvim は確かに素晴らしいが、最近は作者が snack.nvim や mini.nvim のような有名オープンソースプラグインを自分で次々に実装していて、ユーザーロックインのように感じる。こういう模倣/キルゾーン戦略は理解しがたい

    • 中にはメンテナンスもされず放置されているパッケージもある（例: snacks）。ちなみに mini.nvim はまったく別の作者で、lazy とは無関係だ

    • それでも lazy の作者には、自分なりのやり方で質の高いインターフェースを作る力があると思う。自分はその作り方がかなり好きで、しばしば最高だと思ってしまう。Snacks picker はその好例で、最良の選択肢になっている

  • 自分は長年の vim ユーザーだが、neovim でプラグインを盛って使うのは結局あまり良くないという結論になった。何かしら壊れ続ける。むしろ主要プラグイン（LSP、tree sitter）をネイティブ統合したほうが neovim はもっと伸びると思う

    • 自分も同じ感想だったし、C/C++ 開発では vim-plug、gutentags(ctags)、ALE を使って十分やっていけた。でも Web 開発でさまざまな文法やツールを使うようになって、結局 neovim ディストロに乗り換えた。いろいろなディストロを使ったが、（今は終了した）Lunarvim と、現在は Astronvim が自分には合っていた

    • 実際には tree-sitter と LSP はすでにネイティブ統合されている。主要な LSP/tree-sitter プラグインは、主にデフォルト設定とクエリのバンドルを提供しているだけで、将来的には nvim-treesitter に依存しないようクエリ自体を neovim がネイティブにバンドルする計画もある。LSP の設定もかなり簡単になっていて、たとえば

      vim.lsp.config("expert", {
  cmd = { "expert" },
  root_markers = { "mix.exs", ".git" },
  filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")

      そして "LspAttach" autocmd で LSP ごとの keymap 設定もできる

    • 自分の予想では、今後 5〜10 年のうちには整理されるのではないかと思う

  • かなり長いこと使っているが、何の問題もない: 自分の dotfiles を参照

  • 正直、必ずしもミニマルである必要はなく、ほかに特別な理由がないなら統合ソリューションになってほしい。今は vim pack と git submodule を併用しているが、どの GitHub プロジェクトが最適/推奨/十分にサポートされているのかが分かりづらく、もう一度 nvim パッケージマネージャを選びたくない

  • これが追加された元の issue だ: neovim 公式 issue #20893。neovim プロジェクトの長年の目標だったようだが、なぜそうなのかの説明はなかった。正直、既存のプラグインがすでに素晴らしい役割を果たしていたので、余計な肥大化（bloat）にも感じられた。ただし、そうは思わない人もいたようだ