Neovim Pack

• Neovim ने experimental built-in plugin manager vim.pack पेश किया है, जो अलग external manager के बिना plugin install, version management और delete की सुविधाओं को एकीकृत रूप से उपलब्ध कराता है
• (यह शुरुआती test चरण में है, इसलिए API अक्सर बदल सकती है)

प्रमुख विशेषताएँ

• $XDG_DATA_HOME/nvim/site/pack/core/opt directory के लिए समर्पित management
• plugin का Git repository format में होना अनिवार्य है, और git command (कम से कम version 2.36 या उससे ऊपर) आवश्यक है
• plugin version को semver tag (v1.2.3 जैसे रूप) या branch/commit hash आदि से निर्दिष्ट किया जा सकता है
• install, update, delete, version freeze जैसी सभी कार्रवाइयाँ built-in functions से संभाली जाती हैं

install और update कैसे काम करते हैं

1. vim.pack.add() को init.lua में जोड़ें (कई formats supported हैं)
2. Neovim restart होने पर automatic install हो जाता है
3. vim.pack.update() call करने पर latest version में एक साथ update किया जा सकता है

• update check, preview (LSP-based), और console में confirm/cancel का support

4. version बदलने पर, init.lua में version specification संशोधित करें, फिर vim.pack.update({ '플러그인명' }) चलाएँ
5. version freeze मौजूदा commit hash के आधार पर निर्धारित किया जाता है
6. delete, vim.pack.del() call करके किया जाता है

API के प्रमुख parameters और behavior

• add: plugin list लेता है, और यदि मौजूद न हो तो git clone से download करके version checkout करता है
• update: force flag के साथ immediate/confirmation dialog mode चुना जा सकता है, और बदलावों का रिकॉर्ड nvim-pack.log में रहता है
• हर event (install/update/delete) पर hook उपलब्ध हैं, और plugin metadata expose किया जाता है

ध्यान देने योग्य बातें

• production में यह experimental manager है, इसलिए behavior में अचानक बदलाव हो सकते हैं
• भले ही plugin पहले से disk पर हो, actual version और specified version में mismatch हो सकता है, इसलिए sync के लिए update ज़रूरी है
• delete करते समय add से specification हटाना ज़रूरी है, ताकि दोबारा install न हो

[GN⁺]

Hacker News की राय

• मैं इस अपडेट का बहुत इंतज़ार कर रहा हूँ। उम्मीद है कि nvim plugin community जटिल plugin manager lazy का उपयोग किए बिना plugins को डिफ़ॉल्ट रूप से lazy loading करने की दिशा में आगे बढ़ेगी। nvim के official docs में भी इससे जुड़ा note है, इसलिए उसे देखना चाहिए: nvim lazy loading official docs। व्यक्तिगत रूप से मुझे nvim-neorocks plugin द्वारा सुझाई गई best practices भी बहुत पसंद हैं: nvim-neorocks best practices। हाल में लगता है कि इनमें से कुछ आधिकारिक रूप से merge भी हो गए हैं: neovim PR #29073

  • neovim में setup() model इस्तेमाल करने की वजह से lazy loading पारंपरिक Vim तरीके की तुलना में ज़्यादा पेचीदा लगती है। Vim में सिर्फ variables सेट कर दें तो function चलते समय plugin अपने-आप load हो जाता है। लेकिन lua-आधारित setup में जब कई autocmd एक ही plugin को refer करते हैं, तब सभी को setup() सीधे call करना पड़ता है, इसलिए orchestration थोड़ा ज़्यादा चाहिए होता है।

• ऐसा लगता है कि मैं लगभग हर 3 साल में एक बार (Neo)Vim package manager बदलता रहा हूँ। मेरी यात्रा pathogen → Vundle → vim-plug → lazy.nvim रही है। उम्मीद है कि यह मेरा आख़िरी Vim package manager होगा।

  • मुझे अब भी लगता है कि Plug काफ़ी उपयोगी है। यह नया built-in version भाषा में ही शामिल है, इसलिए मुझे लगता है कि यह ज़्यादा users को संतुष्ट करने वाला endgame हो सकता है। मैंने इसे खुद इस्तेमाल किया है; lazy की कुछ खास features का उपयोग नहीं किया, फिर भी यह बिना किसी दिक्कत के ठीक चला।

  • आखिरकार यह आधिकारिक रूप से built-in official package manager बन गया है, यह देखकर अच्छा लगा। आगे चलकर शायद यही सबसे व्यापक रूप से supported और इस्तेमाल किया जाने वाला विकल्प बनेगा (हालाँकि feature richness अलग हो सकती है)।

  • मुझे lazy.nvim भी बहुत शक्तिशाली लगता है। लेकिन जब अलग-अलग plugins कई तरह के package managers को support करते हैं, तब कुछ स्तर की एकरूपता भी ज़रूरी लगती है। lazy.nvim जितना तेज़ और भरोसेमंद कुछ बन पाएगा या नहीं, यह तय नहीं है, लेकिन असंभव भी नहीं लगता।

  • मैंने nixvim इस्तेमाल करना शुरू कर दिया है। vim-plug के समय के आसपास मैंने बस हार मान ली थी। कई machines और अलग-अलग OS पर config को लगातार सही रखना बहुत मुश्किल था।

  • Nix में चीज़ें हमेशा एक जैसी चलती हैं। NixOS, MacOS, Linux के nix-managed home-manager में इसे इस तरह configure किया जा सकता है:

    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 users के लिए मददगार हो सकता है, इसलिए मैंने हाल ही में lazy.nvim से सिर्फ vim.pack इस्तेमाल करने वाले setup में migration किया: यह Pull Request देखें। कोई समस्या नहीं आई, और मैं लगभग 50 plugins ही इस्तेमाल करता हूँ। यह उम्मीद से कहीं आसान निकला, और एक दोस्त की मदद से मैंने plugin loading को lazy जैसा व्यवहार देने वाला setup भी बना लिया। खासकर work computer पर lazy.nvim के साथ 300ms लगने वाला plugin loading अब 80ms तक आ गया है।

  • जानकारी के लिए, वह लिंक diff में एक असंबंधित file पर जा रहा है।

• जब भी मैं देखता हूँ कि git से code import किया जा सकता है और branch या commit hash तक specify किया जा सकता है, तब मैं “किसी खास समय का branch checkout” feature की documentation चाहता हूँ। कई Vim plugin branches versioning भी नहीं करतीं। उदाहरण के लिए, git checkout 'master@{2025-05-26 18:30:00}' जैसे तरीके से किसी खास datetime के अनुरूप checkout किया जा सकता है। उम्मीद यही है कि इससे leftPad जैसी गड़बड़ियों या xz security incident जैसी version management failures से बचा जा सके।

  • यह दिलचस्प idea लगता है, लेकिन सवाल उठता है: “यह किस घड़ी के समय पर आधारित होगा?” repository की अपनी clock, मेरी machine की clock, या remote git की clock? आम तौर पर hash का उपयोग करना सही है, और समय-आधारित software development मैं recommend नहीं करूँगा (जब तक कि वह आख़िरी विकल्प न हो)।

  • मुझे supply chain attacks का जोखिम जानने में दिलचस्पी है। मैं जानना चाहता हूँ कि VIM plugins के पास किस स्तर की permissions होती हैं।

  • अगर आप किसी तय समय का master checkout करते हैं, तो जो चीज़ मिलती है वह उस समय की नहीं बल्कि आपके pull करने के समय पर निर्भर हो सकती है, इसलिए यह भ्रम पैदा करता है (reproducibility नहीं मिलती)। अगर असली reproducibility चाहिए तो git log --before=time जैसे और जटिल तरीकों की ज़रूरत होगी।

  • क्या सिर्फ SHA इस्तेमाल करना काफ़ी नहीं होगा?

• Vim plugin manager अनिवार्य नहीं है, खासकर जब आप अपने dotfiles को git से manage करते हों। आपको बस plugin files को किसी तय directory में clone करना होता है। अगर config भी git से manage हो रही हो, तो plugin versions को pin करके track करने के लिए git submodules इस्तेमाल किए जा सकते हैं। यह तरीका version pinning के लिए भी अच्छा है।

  • मैंने भी 1 साल तक git submodule इस्तेमाल किया था। प्रेरणा यह थी कि हर tool-specific package manager को submodule से बदला जा सकता है (vim, tmux, zsh आदि)। लेकिन व्यवहार में submodule management, vim-plug की तुलना में बहुत झंझटभरा था। विचार अच्छा है, मगर Git में ergonomics कमज़ोर है, इसलिए आखिरकार मैं वापस लौट आया। अगर किसी ने built-in vim pack इस्तेमाल करके इसे vim-plug से भी ज़्यादा सुविधाजनक पाया हो, तो उसका अनुभव सुनना चाहूँगा।

  • मुझे plugins को अक्सर on/off करने की ज़रूरत पड़ती है, इसलिए साधारण filesystem की जगह config के ज़रिए manage करना ज़्यादा सुविधाजनक है। और file type के हिसाब से plugins को activate करना भी आसान हो जाता है। सच कहूँ तो ज़्यादातर plugin managers आखिरकार git के wrapper ही हैं।

• अभी यह काफ़ी शुरुआती/कच्ची हालत में है, लेकिन अगर कभी मैं lazy छोड़ूँ, तो मैं चाहूँगा कि deferred load implement हो। lazy.nvim निस्संदेह शानदार है, लेकिन हाल में ऐसा लगता है कि उसके author ने snack.nvim, mini.nvim जैसे लोकप्रिय open source plugins की functionality खुद implement करके एक तरह का user lock-in बनाया है। यह copycat/kill-zone strategy मुझे समझ नहीं आती।

  • कुछ packages तो maintained भी नहीं हैं और बस छोड़ दिए गए हैं (उदाहरण: snacks)। वैसे mini.nvim का author पूरी तरह अलग है; उसका lazy से कोई संबंध नहीं है।

  • फिर भी, मुझे लगता है कि lazy के author में अपने तरीके से high-quality interfaces बनाने की असाधारण क्षमता है। मुझे उनका approach काफ़ी पसंद है, इसलिए अक्सर वह सबसे बेहतर लगता है। Snacks picker इसका एक बढ़िया उदाहरण है, जो शायद सबसे अच्छे विकल्पों में से एक बन गया है।

• मैं पुराना vim user हूँ, लेकिन मैंने यह निष्कर्ष निकाला है कि neovim को plugins के साथ इस्तेमाल करना अंततः इतना अच्छा नहीं है। कुछ-न-कुछ टूटता ही रहता है। मुझे लगता है कि अगर core plugins (LSP, tree sitter) को native रूप से integrate कर दिया जाए, तो neovim ज़्यादा आगे बढ़ेगा।

  • मुझे भी ऐसा ही लगा था, और C/C++ development के लिए मैं vim-plug, gutentags (ctags), और ALE के साथ ठीक-ठाक काम चला रहा था। लेकिन web development में कई syntaxes और tools की ज़रूरत पड़ी, तो आखिरकार मैं neovim distro पर चला गया। मैंने कई distributions आज़माए; (अब बंद हो चुका) Lunarvim और फिलहाल Astronvim मेरे लिए अच्छे रहे।

  • असल में tree-sitter और LSP पहले से ही native रूप से integrated हैं। मुख्य LSP/tree-sitter plugins ज़्यादातर default configuration और query bundles ही देते हैं, और भविष्य में neovim की योजना है कि queries को खुद native रूप से bundle करे ताकि nvim-treesitter पर निर्भरता कम हो। LSP configuration भी अब बहुत आसान हो गया है, उदाहरण के लिए:

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

    और "LspAttach" autocmd में हर LSP के लिए keymap भी configure किया जा सकता है।

  • मेरा अनुमान है कि अगले 5~10 सालों में चीज़ें काफ़ी हद तक व्यवस्थित हो जाएँगी।

• मैं इसे काफ़ी समय से इस्तेमाल कर रहा हूँ और कोई समस्या नहीं हुई: मेरे dotfiles देखें

• सच कहूँ तो इसका बहुत minimal होना भी ज़रूरी नहीं है; बस अगर कोई खास वजह न हो तो मैं चाहता हूँ कि यह एक integrated solution बने। अभी मैं vim pack और git submodule दोनों का मिश्रण इस्तेमाल करता हूँ, लेकिन कौन-सा GitHub project सबसे अच्छा/अनुशंसित/अच्छी तरह supported है, इसे लेकर इतनी उलझन है कि मैं फिर से कोई nvim package manager चुनना नहीं चाहता।

• यह वही original issue है जिसमें इसे जोड़ा गया था: neovim official issue #20893। लगता है कि यह neovim project का काफ़ी पुराना लक्ष्य था, लेकिन क्यों, इसकी कोई व्याख्या नहीं दी गई थी। सच कहूँ तो मुझे लगा था कि यह थोड़ा bloat है, क्योंकि मौजूदा plugins पहले से ही बहुत अच्छा काम कर रहे थे। लेकिन लगता है कुछ लोग सहमत नहीं थे।

  • उस issue में explanation शामिल है, इसलिए उसे देखें: उस issue का विवरण