Neovim Pack

 (neovim.io)
1 poin oleh GN⁺ 2025-09-06 | 1 komentar | Bagikan ke WhatsApp
  • Neovim memperkenalkan manajer plugin bawaan eksperimental vim.pack, yang mengintegrasikan fungsi instalasi, pengelolaan versi, dan penghapusan plugin tanpa memerlukan manajer eksternal terpisah
  • (Karena masih tahap pengujian awal, API dapat sering berubah)

Fitur utama

  • Khusus mengelola direktori $XDG_DATA_HOME/nvim/site/pack/core/opt
  • Plugin harus berbentuk repositori Git, dan memerlukan perintah git (minimal versi 2.36 atau lebih baru)
  • Versi plugin dapat ditentukan dengan tag semver (bentuk v1.2.3) atau branch/hash commit
  • Semua operasi seperti instalasi, pembaruan, penghapusan, dan pembekuan versi (freeze) ditangani oleh fungsi bawaan

Cara kerja instalasi dan pembaruan

  1. Tambahkan vim.pack.add() ke init.lua (mendukung berbagai format)
  2. Instalasi dijalankan otomatis saat Neovim dimulai ulang
  3. Saat vim.pack.update() dipanggil, semua plugin dapat diperbarui sekaligus ke versi terbaru
  • Mendukung pemeriksaan pembaruan, pratinjau (berbasis LSP), serta konfirmasi/pembatalan di konsol
  1. Saat mengganti versi, ubah spesifikasi versi di init.lua, lalu jalankan vim.pack.update({ 'nama-plugin' })
  2. freeze versi ditetapkan berdasarkan hash commit saat ini
  3. Penghapusan dilakukan dengan memanggil vim.pack.del()

Parameter dan perilaku API utama

  • add: menerima daftar plugin; jika belum ada, akan mengunduh dengan git clone lalu checkout versi yang ditentukan
  • pembaruan: dengan flag force, bisa memilih mode langsung/dialog konfirmasi, dan riwayat perubahan dicatat di nvim-pack.log
  • Hook disediakan untuk setiap event (instalasi/pembaruan/penghapusan), beserta metadata plugin yang diekspos

Hal yang perlu diperhatikan

  • Karena ini manajer eksperimental, di lingkungan produksi ada kemungkinan perubahan perilaku yang mendadak
  • Meski plugin sudah ada di disk, versi aktual dan versi yang ditentukan bisa tidak cocok, sehingga sinkronisasi lewat update wajib dilakukan
  • Saat menghapus, spesifikasi juga harus dihapus dari add agar tidak terinstal ulang

Bacaan terkait

1 komentar

 
GN⁺ 2025-09-06
Opini Hacker News

  • Saya sangat menantikan pembaruan ini; saya berharap komunitas plugin nvim berkembang ke arah plugin yang melakukan lazy loading secara bawaan tanpa memakai lazy, pengelola plugin yang kompleks. Ada catatan terkait di dokumentasi resmi nvim, jadi semoga itu dijadikan acuan. Lihat dokumentasi resmi lazy loading nvim. Secara pribadi saya juga sangat menyukai best practices yang diusulkan oleh plugin nvim-neorocks, lihat nvim-neorocks best practices. Sepertinya sebagian dari ini baru-baru ini sudah digabungkan secara resmi, lihat neovim PR #29073

    • Karena memakai model setup() di neovim, saya merasa lazy loading jadi lebih rumit dibanding cara lama Vim; di Vim cukup set variabel lalu plugin akan dimuat otomatis saat fungsi dijalankan. Di basis lua, ketika beberapa autocmd merujuk plugin yang sama, semuanya harus memanggil setup() sendiri, jadi perlu orkestrasi tambahan

  • Rasanya saya pindah-pindah pengelola paket (Neo)Vim kira-kira setiap 3 tahun sekali; perjalanan saya adalah pathogen → Vundle → vim-plug → lazy.nvim. Semoga ini jadi pengelola paket Vim terakhir saya

    • Menurut saya Plug masih layak dipakai; versi bawaan kali ini terasa seperti endgame yang bisa memuaskan lebih banyak pengguna karena sudah tertanam di bahasa. Saya sudah mencobanya langsung, memang saya tidak memakai fitur-fitur khusus yang disediakan lazy, tapi tetap berjalan dengan baik tanpa masalah

    • Senang akhirnya ada pengelola paket resmi yang secara resmi dibundel; ke depan kemungkinan besar ini yang paling luas didukung dan digunakan (meski tentu kelengkapan fiturnya bisa berbeda)

    • Saya juga menganggap lazy.nvim sangat kuat, tetapi karena banyak plugin mendukung berbagai pengelola paket yang berbeda-beda, menurut saya tingkat keseragaman tertentu juga perlu. Saya ragu bisa muncul sesuatu yang secepat dan seterpercaya lazy.nvim, tetapi rasanya bukan hal yang mustahil

    • Saya mulai menggunakan nixvim; saya sudah menyerah sekitar masa vim-plug. Menjaga konfigurasi tetap rapi di banyak mesin dan berbagai OS selalu terasa menyiksa

    • Di Nix semuanya selalu bekerja dengan cara yang sama. Di NixOS, MacOS, Linux dengan home-manager yang dikelola nix, bisa dikonfigurasi seperti ini

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

  • Saya baru-baru ini bermigrasi dari lazy.nvim ke cara yang hanya memakai vim.pack, semoga ini membantu pengguna neovim. Lihat Pull Request ini. Tidak ada masalah sama sekali, saya hanya memakai sekitar 50 plugin, dan ternyata jauh lebih mudah dari perkiraan. Seorang kenalan juga membantu membuat konfigurasi agar plugin dimuat mirip seperti di lazy, dan khususnya di komputer kerja saya, waktu pemuatan plugin yang tadinya 300ms dengan lazy.nvim sekarang turun hingga 80ms

    • Sebagai catatan, tautan itu mengarah ke file yang tidak terkait di diff

  • Setiap kali saya melihat fitur yang memungkinkan impor kode dari git dan bahkan bisa menentukan branch atau hash commit, saya berharap ada dokumentasi untuk fitur “checkout branch pada titik waktu tertentu”. Banyak branch plugin Vim bahkan tidak dikelola versinya. Misalnya, kita bisa checkout sesuai datetime tertentu seperti git checkout 'master@{2025-05-26 18:30:00}'. Harapannya ini bisa membantu mencegah kegagalan pengelolaan versi seperti bencana leftPad atau insiden keamanan xz

    • Kedengarannya seperti ide yang menarik, tetapi saya langsung bertanya, “jam yang mana yang dijadikan acuan untuk titik waktu itu?” Apakah jam bawaan repositori, jam komputer saya, atau jam git remote? Secara umum memakai hash memang benar, dan saya tidak merekomendasikan pengembangan perangkat lunak berbasis waktu kecuali benar-benar jalan terakhir

    • Saya penasaran dengan risiko serangan supply chain; saya ingin tahu plugin VIM punya tingkat izin seperti apa

    • Kalau checkout master pada titik waktu tertentu, yang jadi acuan bukan saat itu diambil melainkan saat saya melakukan pull, jadi membingungkan (tidak reproducible). Kalau benar-benar ingin reproducibility, perlu cara yang lebih rumit seperti git log —before=time dan seterusnya

    • Kenapa tidak cukup pakai SHA saja?

  • Pengelola plugin Vim sebenarnya tidak wajib, terutama jika dotfiles dikelola dengan git; cukup clone file plugin ke direktori yang ditentukan. Jika konfigurasi juga dikelola dengan git, versi plugin bisa dipatok dan dilacak dengan git submodules. Cara ini juga menguntungkan untuk version pinning

    • Saya juga pernah memakai git submodule selama setahun; motivasinya adalah gagasan bahwa semua pengelola paket khusus alat bisa diganti dengan submodule (vim, tmux, zsh, dan lain-lain). Tetapi dalam praktiknya, mengelola submodule jauh lebih merepotkan dibanding vim-plug. Konsepnya bagus, tetapi ergonomi di Git terasa buruk, jadi akhirnya saya kembali lagi. Kalau ada yang punya pengalaman bahwa memakai vim pack bawaan terasa lebih mudah daripada vim-plug, saya ingin mendengarnya

    • Saya perlu cukup sering mengaktifkan dan menonaktifkan plugin, jadi bagi saya menggunakan config lebih nyaman daripada sekadar filesystem. Selain itu, plugin juga mudah diaktifkan berdasarkan file type. Sebenarnya saya rasa sebagian besar pengelola plugin pada akhirnya hanyalah wrapper untuk git

  • Ini masih dalam keadaan yang cukup mentah, tetapi kalau suatu hari saya meninggalkan lazy, saya berharap deferred load sudah diimplementasikan. lazy.nvim memang jelas hebat, tetapi akhir-akhir ini saya merasa penulisnya menunjukkan kecenderungan lock-in pengguna dengan langsung mengimplementasikan sendiri plugin open source terkenal seperti snack.nvim dan mini.nvim. Saya tidak mengerti strategi copycat/kill zone seperti ini

    • Bahkan beberapa paket ada yang tidak dipelihara dan dibiarkan terbengkalai (misalnya: snacks). Sebagai catatan, mini.nvim itu penulisnya sepenuhnya berbeda, terpisah dari lazy

    • Meski begitu, saya melihat penulis lazy memang punya kemampuan membuat antarmuka berkualitas dengan gayanya sendiri. Saya cukup menyukai pendekatan itu sampai sering merasa itu yang terbaik. Snacks picker adalah contoh yang menjadi pilihan terbaik

  • Saya pengguna vim lama, tetapi saya sampai pada kesimpulan bahwa memakai neovim dengan banyak plugin pada akhirnya kurang bagus; selalu ada saja yang rusak. Menurut saya neovim akan lebih maju kalau plugin inti (LSP, tree sitter) diintegrasikan secara native

    • Saya juga merasakan hal yang sama, dan untuk pengembangan C/C++ saya cukup bertahan dengan vim-plug, gutentags(ctags), dan ALE. Tapi saat mulai mengerjakan web development dengan berbagai sintaks dan alat, saya akhirnya pindah ke distro neovim. Saya sudah mencoba beberapa distro, dan yang paling cocok buat saya adalah Lunarvim (yang sekarang sudah dihentikan) dan saat ini Astronvim

    • Sebenarnya tree-sitter dan LSP sudah terintegrasi secara native; plugin LSP/tree-sitter utama pada dasarnya hanya menyediakan konfigurasi default dan bundel query, dan ke depannya neovim juga berencana membundel query itu sendiri secara native agar tidak lagi bergantung pada nvim-treesitter. Konfigurasi LSP juga sekarang sangat mudah, misalnya

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

      Dan Anda juga bisa mengatur keymap per LSP di autocmd "LspAttach"

    • Prediksi saya, dalam 5~10 tahun ke depan semuanya mungkin akan lebih rapi

  • Saya sudah memakainya cukup lama dan tidak ada masalah sama sekali, lihat dotfiles saya

  • Sejujurnya, tidak harus minimalis sekali; kecuali ada alasan khusus lain, saya ingin ini menjadi solusi terpadu. Saat ini saya memakai vim pack bersama git submodule, tetapi saya bingung proyek GitHub mana yang paling optimal/direkomendasikan/didukung, jadi saya tidak ingin harus memilih pengelola paket nvim lagi

  • Ini issue asli saat fitur ini ditambahkan, lihat issue resmi neovim #20893. Sepertinya ini memang tujuan lama proyek Neovim, tetapi tidak ada penjelasan kenapa. Terus terang, karena plugin yang sudah ada selama ini juga bekerja dengan sangat baik, saya sempat merasa ini seperti bloat yang tidak perlu. Namun tampaknya ada juga yang tidak setuju