Neovim Pack

 (neovim.io)
1 điểm bởi GN⁺ 2025-09-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Neovim giới thiệu trình quản lý plugin tích hợp thử nghiệm vim.pack, cung cấp thống nhất các chức năng cài đặt, quản lý phiên bản và xóa plugin mà không cần trình quản lý bên ngoài riêng biệt
  • (Vì đang ở giai đoạn thử nghiệm ban đầu nên API có thể thay đổi thường xuyên)

Tính năng chính

  • Quản lý chuyên dụng thư mục $XDG_DATA_HOME/nvim/site/pack/core/opt
  • Plugin bắt buộc phải ở dạng Git repository và cần có lệnh git (tối thiểu phiên bản 2.36 trở lên)
  • Phiên bản plugin có thể được chỉ định bằng thẻ semver (dạng v1.2.3) hoặc branch/hash commit
  • Mọi thao tác như cài đặt, cập nhật, xóa, cố định phiên bản (freeze) đều được xử lý bằng hàm tích hợp

Cách hoạt động của cài đặt và cập nhật

  1. Thêm vim.pack.add() vào init.lua (hỗ trợ nhiều định dạng)
  2. Tự động cài đặt khi khởi động lại Neovim
  3. Khi gọi vim.pack.update(), có thể cập nhật hàng loạt lên phiên bản mới nhất
  • Hỗ trợ kiểm tra cập nhật, xem trước (dựa trên LSP), xác nhận/hủy trong console
  1. Khi thay đổi phiên bản, chỉnh lại chỉ định phiên bản trong init.lua, sau đó chạy vim.pack.update({ 'tên plugin' })
  2. Freeze phiên bản được chỉ định dựa trên hash commit hiện tại
  3. Việc xóa được xử lý bằng cách gọi vim.pack.del()

Tham số API chính và cách hoạt động

  • add: nhận danh sách plugin, nếu chưa có thì tải bằng git clone và checkout phiên bản
  • cập nhật: có thể chọn chế độ thực thi ngay/hộp thoại xác nhận bằng cờ force, lịch sử thay đổi được ghi vào "nvim-pack.log"
  • Cung cấp hook cho từng sự kiện (cài đặt/cập nhật/xóa), đồng thời hiển thị thông tin metadata của plugin

Ghi chú

  • Trong môi trường production, vì đây là trình quản lý thử nghiệm nên có thể có thay đổi hành vi đột ngột
  • Ngay cả khi plugin đã có sẵn trên đĩa, phiên bản thực tế và phiên bản được chỉ định vẫn có thể không khớp, nên cần đồng bộ bằng update
  • Khi xóa, cần loại bỏ đặc tả khỏi add để tránh bị cài lại

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-09-06
Ý kiến trên Hacker News

  • Tôi rất mong chờ bản cập nhật này, và hy vọng cộng đồng plugin nvim sẽ phát triển theo hướng plugin mặc định hỗ trợ lazy loading mà không cần dùng các trình quản lý plugin phức tạp như lazy, trong tài liệu chính thức của nvim cũng có ghi chú liên quan nên mong mọi người tham khảo tài liệu chính thức về lazy loading của nvim, cá nhân tôi cũng rất thích các best practices được đề xuất trong plugin nvim-neorocks nvim-neorocks best practices, có vẻ gần đây một phần trong đó đã được merge chính thức neovim PR #29073

    • Vì dùng mô hình setup() trong neovim, tôi có cảm giác lazy loading trở nên khó hơn so với cách làm cũ của Vim, ở Vim chỉ cần đặt biến là plugin sẽ tự được load khi hàm chạy, còn với Lua thì khi nhiều autocmd cùng tham chiếu một plugin, tất cả đều phải tự gọi setup(), nên cần orchestration nhiều hơn một chút

  • Tôi có cảm giác cứ khoảng 3 năm lại chuyển trình quản lý gói (Neo)Vim một lần, hành trình của tôi là pathogen → Vundle → vim-plug → lazy.nvim, hy vọng đây sẽ là trình quản lý gói Vim cuối cùng của tôi

    • Tôi vẫn thấy Plug còn dùng tốt, còn phiên bản tích hợp lần này vì nằm sẵn trong ngôn ngữ nên có thể là kiểu endgame làm hài lòng được nhiều người hơn, tôi đã thử dùng trực tiếp, tuy không dùng các tính năng đặc biệt mà lazy cung cấp nhưng nó hoạt động ổn và trơn tru

    • Tôi rất vui vì cuối cùng cũng có một trình quản lý gói chính thức được tích hợp chính thức, tôi nghĩ về sau đây sẽ là lựa chọn được hỗ trợ và sử dụng rộng rãi nhất (dù độ phong phú tính năng có thể khác)

    • Tôi cũng nghĩ lazy.nvim rất mạnh, nhưng vì nhiều plugin hiện hỗ trợ các trình quản lý gói khác nhau nên tôi cho rằng cũng cần một mức độ thống nhất nào đó, tôi nghi ngờ liệu có thể xuất hiện thứ gì nhanh và đáng tin như lazy.nvim hay không, nhưng có lẽ cũng không phải là bất khả thi

    • Tôi đã bắt đầu dùng nixvim, đến thời vim-plug thì tôi gần như đã bỏ cuộc. Việc giữ cấu hình luôn ổn định trên nhiều máy và nhiều OS khác nhau là một cực hình

    • Trên Nix thì mọi thứ luôn hoạt động theo cùng một cách. Có thể cấu hình như sau trong home-manager do nix quản lý trên NixOS, MacOS, Linux

      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;
}

  • Tôi vừa migrate từ lazy.nvim sang cách chỉ dùng vim.pack để xem có giúp ích gì cho người dùng neovim không xem Pull Request này, không gặp vấn đề gì cả và tôi chỉ dùng khoảng 50 plugin, dễ hơn nhiều so với dự đoán và nhờ một người quen giúp đỡ, tôi đã tạo được cấu hình load plugin khá giống lazy, đặc biệt trên máy làm việc thì thời gian load plugin trước đây mất 300ms với lazy.nvim giờ giảm còn 80ms

    • Nhân tiện, link đó hiện đang trỏ tới một file không liên quan trong phần diff

  • Mỗi khi thấy khả năng import code từ git, và còn chỉ định được cả branch hay commit hash, tôi lại mong có tài liệu hóa cho tính năng “checkout branch tại một thời điểm cụ thể”, vì nhiều branch plugin Vim thậm chí còn không quản lý version, ví dụ có thể checkout theo một datetime cụ thể như git checkout 'master@{2025-05-26 18:30:00}', hy vọng cách này có thể giúp tránh các thất bại quản lý version kiểu thảm họa leftPad hay sự cố bảo mật xz

    • Nghe có vẻ là một ý tưởng thú vị, nhưng tôi thắc mắc “dựa theo đồng hồ của thời điểm nào?”, là đồng hồ nội tại của repository, đồng hồ máy tôi hay đồng hồ git từ remote, thông thường dùng hash là đúng hơn, còn phát triển phần mềm dựa trên thời gian thì tôi không khuyến khích (trừ khi là biện pháp cuối cùng)

    • Tôi tò mò về mức độ rủi ro của tấn công chuỗi cung ứng, muốn biết plugin VIM có mức quyền hạn đến đâu

    • Nếu checkout master tại một thời điểm chỉ định thì nó không lấy đúng thời điểm đó, mà lại phụ thuộc vào thời điểm tôi pull, nên rất dễ gây rối (không có tính tái lập), nếu muốn tái lập thực sự thì cần các cách phức tạp hơn như git log —before=time

    • Không biết chỉ dùng SHA thì có được không

  • Thực ra không nhất thiết phải có trình quản lý plugin Vim, nhất là khi quản lý dotfiles bằng git, chỉ cần clone file plugin vào thư mục chỉ định là được, nếu cấu hình cũng được quản lý bằng git thì có thể theo dõi và cố định version plugin bằng git submodules. Cách này cũng có lợi cho việc pin version

    • Tôi cũng từng dùng git submodule trong 1 năm, động lực là ý tưởng có thể thay mọi trình quản lý gói chuyên biệt cho từng công cụ bằng submodule (vim, tmux, zsh, v.v.), nhưng trên thực tế việc quản lý submodule phiền phức hơn rất nhiều so với vim-plug, ý tưởng thì hay nhưng ergonomics của Git không tốt, cuối cùng tôi quay lại. Nếu ai có trải nghiệm dùng vim pack tích hợp sẵn mà thấy còn tiện hơn vim-plug thì mong chia sẻ

    • Tôi cần thường xuyên bật tắt plugin nên làm bằng config sẽ tiện hơn so với filesystem đơn thuần, và cũng dễ kích hoạt plugin theo file type, thật ra tôi nghĩ phần lớn trình quản lý plugin rốt cuộc cũng chỉ là wrapper cho git mà thôi

  • Nó vẫn còn khá thô sơ, nhưng nếu một ngày tôi bỏ lazy thì tôi muốn deferred load được triển khai, lazy.nvim rõ ràng rất xuất sắc, nhưng gần đây tôi có cảm giác tác giả đang trực tiếp tự làm ra các plugin mã nguồn mở nổi tiếng như snack.nvim, mini.nvim để khóa người dùng vào hệ sinh thái của mình, kiểu chiến lược copycat/kill zone này tôi không hiểu nổi

    • Thậm chí một số package còn không được bảo trì mà bị bỏ mặc (ví dụ: snacks), và xin nói thêm mini.nvim là của một tác giả hoàn toàn khác, không liên quan đến lazy

    • Dù vậy tôi vẫn nghĩ tác giả của lazy có năng lực tạo ra những interface chất lượng theo cách riêng của mình, tôi khá thích cách làm đó nên thường cảm thấy đó là lựa chọn tốt nhất. Snacks picker là ví dụ điển hình cho lựa chọn tốt nhất

  • Tôi là người dùng vim lâu năm, nhưng cuối cùng kết luận rằng dùng neovim với plugin thì không thật sự ổn, cứ liên tục có thứ bị hỏng. Tôi nghĩ neovim sẽ tốt hơn nếu tích hợp native các plugin cốt lõi như LSP, tree sitter

    • Tôi cũng từng thấy như vậy, và với phát triển C/C++ thì tôi vẫn dùng ổn với vim-plug, gutentags(ctags), ALE. Nhưng khi làm web với nhiều cú pháp và công cụ khác nhau, cuối cùng tôi chuyển sang distro neovim. Tôi đã thử nhiều bản phân phối, trong đó Lunarvim (nay đã ngừng) và hiện tại là Astronvim là hợp nhất với tôi

    • Thực ra tree-sitter và LSP đã được tích hợp native rồi, các plugin LSP/tree-sitter chính chủ yếu chỉ cung cấp cấu hình mặc định và bundle query, và về sau neovim cũng dự định bundle các query đó theo kiểu native để không còn phụ thuộc vào nvim-treesitter. Việc cấu hình LSP giờ cũng rất dễ, ví dụ như

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

      Và cũng có thể thiết lập keymap riêng cho từng LSP trong autocmd "LspAttach"

    • Tôi đoán trong khoảng 5~10 năm tới mọi thứ sẽ được dọn dẹp gọn gàng hơn

  • Tôi đã dùng khá lâu rồi và không có vấn đề gì cả xem dotfiles của tôi

  • Thành thật mà nói cũng không nhất thiết phải tối giản, nếu không có lý do đặc biệt nào khác thì tôi muốn nó trở thành một giải pháp tích hợp. Hiện tại tôi đang dùng kết hợp vim pack và git submodule, nhưng quá rối vì không rõ dự án GitHub nào là tối ưu/được khuyến nghị/được hỗ trợ tốt, nên tôi không muốn lại phải chọn một trình quản lý gói nvim nữa

  • Đây là issue gốc khi tính năng này được thêm vào neovim issue chính thức #20893, có vẻ đó là mục tiêu lâu năm của dự án neovim, nhưng không có giải thích vì sao. Thành thật mà nói tôi thấy nó hơi giống bloat vì các plugin hiện có đã làm rất tốt rồi. Nhưng có vẻ một số người không đồng ý