Neovim Pack

 (neovim.io)
1 คะแนน โดย GN⁺ 2025-09-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Neovim เปิดตัว vim.pack ซึ่งเป็น ตัวจัดการปลั๊กอินแบบฝังในตัวที่ยังอยู่ในขั้นทดลอง โดยรวมความสามารถในการติดตั้ง จัดการเวอร์ชัน และลบปลั๊กอินไว้ในตัวโดยไม่ต้องพึ่งตัวจัดการภายนอก
  • (เนื่องจากยังอยู่ในช่วงทดสอบระยะแรก API อาจมีการเปลี่ยนแปลงบ่อย)

คุณสมบัติหลัก

  • จัดการเฉพาะไดเรกทอรี $XDG_DATA_HOME/nvim/site/pack/core/opt
  • ปลั๊กอินต้องอยู่ในรูปแบบ Git repository เท่านั้น และจำเป็นต้องมีคำสั่ง git (อย่างน้อยเวอร์ชัน 2.36 ขึ้นไป)
  • เวอร์ชันของปลั๊กอินสามารถระบุได้ด้วยแท็ก semver (รูปแบบ v1.2.3) หรือ branch/commit hash
  • ทุกงาน เช่น ติดตั้ง อัปเดต ลบ และตรึงเวอร์ชัน (freeze) จัดการได้ผ่านฟังก์ชันที่มีมาในตัว

วิธีการทำงานของการติดตั้งและอัปเดต

  1. เพิ่ม vim.pack.add() ลงใน init.lua (รองรับหลายรูปแบบ)
  2. เมื่่อรีสตาร์ต Neovim ระบบจะติดตั้งให้อัตโนมัติ
  3. เมื่อเรียก vim.pack.update() จะสามารถอัปเดตทั้งหมดเป็นเวอร์ชันล่าสุดได้
  • รองรับการตรวจสอบอัปเดต การแสดงตัวอย่างล่วงหน้า (อิง LSP) และการยืนยัน/ยกเลิกในคอนโซล
  1. เมื่อต้องการเปลี่ยนเวอร์ชัน ให้แก้การระบุเวอร์ชันใน init.lua แล้วรัน vim.pack.update({ 'ชื่อปลั๊กอิน' })
  2. การ freeze เวอร์ชันจะอิงตาม commit hash ปัจจุบัน
  3. การลบทำได้ด้วยการเรียก vim.pack.del()

พารามิเตอร์และพฤติกรรมหลักของ API

  • add: รับรายการปลั๊กอิน และหากยังไม่มีจะดาวน์โหลดด้วย git clone และ checkout ไปยัง version ที่ระบุ
  • อัปเดต: สามารถเลือกโหมดทำงานทันที/โหมดถามยืนยันได้ด้วยแฟล็ก force และรายละเอียดการเปลี่ยนแปลงจะถูกบันทึกไว้ใน "nvim-pack.log"
  • มี hook ให้ในแต่ละเหตุการณ์ (ติดตั้ง/อัปเดต/ลบ) พร้อมเปิดเผยข้อมูลเมตาของปลั๊กอิน

หมายเหตุ

  • ในงานโปรดักชัน เนื่องจากเป็นตัวจัดการแบบทดลอง จึงอาจมีการเปลี่ยนพฤติกรรมอย่างฉับพลันได้
  • แม้จะมีปลั๊กอินอยู่บนดิสก์แล้ว เวอร์ชันจริงกับเวอร์ชันที่ระบุอาจไม่ตรงกัน ดังนั้นจึงจำเป็นต้องซิงก์ด้วยการอัปเดต
  • เมื่อลบแล้ว ต้องนำสเปกออกจาก add ด้วยเพื่อป้องกันการติดตั้งใหม่

บทความที่เกี่ยวข้อง

  • Neovim 0.12.0
    2 คะแนน · 1 ความคิดเห็น · 2026-03-30

1 ความคิดเห็น

 
GN⁺ 2025-09-06
ความคิดเห็นบน Hacker News

  • กำลังตั้งตารออัปเดตครั้งนี้มาก หวังว่าคอมมูนิตี้ปลั๊กอินของ nvim จะพัฒนาไปในทิศทางที่ทำให้ปลั๊กอิน lazy load ได้เป็นค่าเริ่มต้นโดยไม่ต้องใช้ตัวจัดการปลั๊กอินที่ซับซ้อนอย่าง lazy และอยากให้ลองดูโน้ตที่เกี่ยวข้องในเอกสารทางการของ nvim ด้วย เอกสารทางการของ nvim เรื่อง lazy loading ส่วนตัวชอบ best practices ที่ปลั๊กอิน nvim-neorocks เสนอไว้มากเช่นกัน nvim-neorocks best practices และดูเหมือนว่าช่วงหลังมีบางส่วนถูกรวมเข้าไปอย่างเป็นทางการแล้ว neovim PR #29073

    • พอใช้โมเดล setup() ใน neovim แล้ว รู้สึกว่า lazy loading ทำได้ยากกว่าวิธีแบบ Vim เดิมอยู่พอสมควร ใน Vim แค่ตั้งค่าตัวแปรไว้ ปลั๊กอินก็จะถูกโหลดเองตอนที่ฟังก์ชันถูกเรียก แต่ในฝั่ง lua ถ้ามีหลาย autocmd อ้างถึงปลั๊กอินตัวเดียวกัน ก็ต้องเรียก setup() เองทุกจุด เลยต้องจัด orchestration เพิ่มขึ้นอีกหน่อย

  • รู้สึกเหมือนตัวเองย้าย (Neo)Vim package manager ทุกประมาณ 3 ปี เส้นทางของฉันคือ pathogen → Vundle → vim-plug → lazy.nvim หวังว่าครั้งนี้จะเป็น package manager ตัวสุดท้ายของ Vim แล้ว

    • ยังคิดว่า Plug ใช้งานได้ดีอยู่ เวอร์ชันที่ฝังมาในตัวครั้งนี้อยู่ในภาษาโดยตรง เลยดูเป็น endgame ที่น่าจะตอบโจทย์ผู้ใช้ได้มากกว่า ลองใช้เองแล้ว ถึงจะไม่ได้ใช้ฟีเจอร์พิเศษที่ lazy มีให้ แต่ก็ทำงานได้ดีแบบไม่มีปัญหา

    • ดีใจที่ในที่สุดก็มี package manager อย่างเป็นทางการที่ฝังมาในตัวอย่างเป็นทางการ คิดว่าจากนี้ไปมันน่าจะเป็นตัวที่มีการรองรับและถูกใช้งานแพร่หลายที่สุด (แน่นอนว่าความครบเครื่องของฟีเจอร์อาจต่างกัน)

    • ก็ยังคิดว่า lazy.nvim ทรงพลังมาก แต่ตอนนี้หลายปลั๊กอินต้องรองรับ package manager หลายแบบ จึงรู้สึกว่าควรมีความเป็นมาตรฐานร่วมกันบ้าง ไม่แน่ใจว่าจะมีอะไรที่เร็วและน่าเชื่อถือได้เท่า 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 ด้วย โดยเฉพาะบนเครื่องที่ใช้ทำงาน เวลาโหลดปลั๊กอินที่เคยใช้ 300ms กับ lazy.nvim ตอนนี้ลดเหลือ 80ms แล้ว

    • เผื่อไว้ก่อน ลิงก์นั้นตอนนี้พาไปยังไฟล์ที่ไม่เกี่ยวข้องใน diff

  • ทุกครั้งที่เห็นว่ามันรองรับการ import โค้ดจาก git ได้ และยังระบุ branch หรือ commit hash ได้ด้วย ก็อยากให้มีเอกสารเรื่องฟีเจอร์ “checkout branch ณ ช่วงเวลาหนึ่ง” มากขึ้น เพราะหลาย branch ของ Vim plugin ไม่มีการทำเวอร์ชันเลย เช่น สามารถใช้ git checkout 'master@{2025-05-26 18:30:00}' เพื่อ checkout ตาม datetime ที่ต้องการได้ หวังว่ามันจะช่วยป้องกันปัญหาแบบ leftPad หรือเหตุการณ์ด้านความปลอดภัยอย่าง xz ที่เกิดจากความล้มเหลวในการจัดการเวอร์ชัน

    • ฟังดูเป็นไอเดียที่น่าสนใจ แต่ก็อดสงสัยไม่ได้ว่า “ยึดเวลาตามนาฬิกาของอะไร” นาฬิกาของ repository เอง ของเครื่องฉัน หรือของ remote git โดยทั่วไปใช้ hash ก็น่าจะถูกทางกว่า และไม่แนะนำการพัฒนาซอฟต์แวร์ที่อิงเวลา (ถ้าไม่ใช่ทางเลือกสุดท้ายจริง ๆ)

    • อยากรู้เรื่องความเสี่ยงจาก supply chain attack เหมือนกัน ไม่แน่ใจว่า VIM plugin มีสิทธิ์มากน้อยแค่ไหน

    • ถ้า checkout master ณ เวลาที่ระบุ มันไม่ได้หมายความว่าจะดึงของ ณ ตอนนั้นจริง ๆ แต่จะอิงจากเวลาที่ฉัน pull ซึ่งทำให้งงอยู่เหมือนกัน (ไม่ reproducible) ถ้าต้องการ reproducibility จริง ๆ คงต้องใช้วิธีซับซ้อนขึ้น เช่น git log --before=time

    • สงสัยว่าทำไมไม่ใช้ SHA ไปเลย

  • จริง ๆ แล้ว Vim plugin manager อาจไม่จำเป็น โดยเฉพาะถ้าจัดการ dotfiles ด้วย git แค่ clone ไฟล์ปลั๊กอินไปไว้ในไดเรกทอรีที่กำหนดก็พอแล้ว ถ้าจัดการคอนฟิกด้วย git เช่นกัน ก็ใช้ git submodules เพื่อตรึงและติดตามเวอร์ชันปลั๊กอินได้ วิธีนี้ยังเหมาะกับการ pin เวอร์ชันด้วย

    • ฉันเองก็เคยใช้ git submodule อยู่ปีหนึ่ง แรงจูงใจคือคิดว่ามันน่าจะแทน package manager เฉพาะทางของทุกเครื่องมือได้ (vim, tmux, zsh ฯลฯ) แต่ในทางปฏิบัติการจัดการ submodule ยุ่งยากกว่า vim-plug มาก แนวคิดดีอยู่หรอก แต่ ergonomics ของ Git ยังไม่ดีพอ สุดท้ายเลยย้อนกลับไป ถ้าใครมีประสบการณ์ว่าใช้ vim pack ที่ฝังมาในตัวแล้วสะดวกกว่า vim-plug อีก ก็อยากให้แชร์

    • ฉันมีความจำเป็นต้องเปิดปิดปลั๊กอินบ่อย ๆ เลยรู้สึกว่าจัดการผ่าน config สะดวกกว่าระบบไฟล์ตรง ๆ และยังเปิดใช้ปลั๊กอินตาม file type ได้ง่ายด้วย จริง ๆ แล้ว package manager ส่วนใหญ่ก็เป็นแค่ wrapper ของ git เท่านั้นเอง

  • ตอนนี้มันยังอยู่ในสภาพค่อนข้างดิบ แต่ถ้าวันหนึ่งฉันเลิกใช้ lazy ก็อยากให้มี deferred load ด้วย lazy.nvim นั้นยอดเยี่ยมแน่นอน แต่ช่วงหลังรู้สึกว่าผู้เขียนกำลังทำพฤติกรรมแบบ lock-in ผู้ใช้ ด้วยการลงมือทำปลั๊กอินโอเพนซอร์สชื่อดังอย่าง snack.nvim, mini.nvim เองไปหมด ไม่ค่อยเข้าใจกลยุทธ์แนว copycat/kill zone แบบนี้

    • แถมบางแพ็กเกจก็ไม่ได้ดูแลต่อด้วย ปล่อยค้างไว้เลย (เช่น snacks) และขอเสริมว่า mini.nvim เป็นคนละผู้เขียนกันโดยสิ้นเชิง ไม่เกี่ยวกับ lazy

    • ถึงอย่างนั้นก็ยังคิดว่าผู้เขียน lazy มีความสามารถในการสร้างอินเทอร์เฟซคุณภาพดีในแบบของตัวเอง ซึ่งฉันค่อนข้างชอบมาก จนบ่อยครั้งรู้สึกว่ามันดีที่สุด ตัวอย่างชัด ๆ คือ Snacks picker ที่กลายเป็นตัวเลือกที่ดีที่สุดไปแล้ว

  • ฉันเป็นผู้ใช้ vim รุ่นเก่า แต่สุดท้ายก็สรุปว่าการใช้ปลั๊กอินบน neovim ไม่ค่อยเวิร์กสำหรับฉัน มันพังอยู่เรื่อย ๆ คิดว่าถ้าเอาปลั๊กอินหลักอย่าง LSP, tree sitter ไปรวมเป็น native เลย neovim น่าจะไปได้ดีกว่านี้

    • ฉันก็รู้สึกแบบเดียวกัน และสำหรับการพัฒนา C/C++ ก็ยังเอาตัวรอดได้ดีด้วย vim-plug, gutentags(ctags), ALE แต่พอมาทำเว็บที่ต้องใช้หลาย syntax และหลายเครื่องมือ สุดท้ายก็ย้ายไปใช้ neovim distro ลองมาหลายตัวแล้ว ทั้ง Lunarvim (ที่ตอนนี้หยุดพัฒนาแล้ว) และตอนนี้ Astronvim ซึ่งเข้ากับฉันได้ดี

    • จริง ๆ แล้ว tree-sitter กับ LSP ถูกรวมแบบ native อยู่แล้ว ปลั๊กอิน LSP/tree-sitter หลัก ๆ มีไว้แค่ให้ค่าเริ่มต้นและ bundle query เท่านั้น และในอนาคตก็มีแผนให้ neovim bundle query เองแบบ native เพื่อไม่ต้องพึ่ง nvim-treesitter อีกต่อไป ส่วนการตั้งค่า LSP ก็ง่ายขึ้นมาก เช่น

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

      และยังตั้ง keymap เฉพาะของแต่ละ LSP ได้ใน autocmd "LspAttach" ด้วย

    • ฉันเดาว่าในอีก 5-10 ปีข้างหน้า เรื่องนี้น่าจะเข้าที่เข้าทางขึ้น

  • ใช้มาค่อนข้างนานแล้วและไม่มีปัญหาอะไรเลย ดู dotfiles ของฉัน

  • พูดตรง ๆ ก็ไม่จำเป็นต้องมินิมอลเสมอไป และถ้าไม่มีเหตุผลเฉพาะอื่น ๆ ก็อยากให้เป็นโซลูชันแบบรวมศูนย์ไปเลย ตอนนี้ฉันใช้ทั้ง vim pack และ git submodule ร่วมกัน แต่รู้สึกสับสนว่าโปรเจ็กต์บน GitHub ไหนคือแบบที่ดีที่สุด/แนะนำ/รองรับดี เลยไม่อยากต้องมาเลือก nvim package manager อีกแล้ว

  • นี่คือออริจินัลอิสชูที่เพิ่มฟีเจอร์นี้เข้าไป neovim issue ทางการ #20893 ดูเหมือนจะเป็นเป้าหมายมานานของโปรเจ็กต์ neovim แต่ไม่มีคำอธิบายว่าทำไมถึงทำ ตรง ๆ เลยตอนแรกฉันรู้สึกว่ามันเหมือน bloat เพราะปลั๊กอินที่มีอยู่เดิมก็ทำหน้าที่นี้ได้ยอดเยี่ยมอยู่แล้ว แต่ดูเหมือนบางคนจะไม่เห็นด้วย