Neovim Pack

 (neovim.io)
1 puntos por GN⁺ 2025-09-06 | 1 comentarios | Compartir por WhatsApp
  • Neovim introduce vim.pack, un gestor de plugins experimental integrado, que ofrece de forma unificada instalación, gestión de versiones y eliminación de plugins sin necesidad de un gestor externo
  • (Como está en una fase inicial de pruebas, la API puede cambiar con frecuencia)

Características principales

  • Gestión dedicada del directorio $XDG_DATA_HOME/nvim/site/pack/core/opt
  • Los plugins deben estar obligatoriamente en formato de repositorio Git, y se requiere el comando git (versión mínima 2.36 o superior)
  • La versión del plugin puede especificarse mediante etiquetas semver (forma v1.2.3) o con rama/hash de commit, entre otros
  • Todas las operaciones, como instalación, actualización, eliminación y fijación de versión (freeze), se manejan con funciones integradas

Cómo funcionan la instalación y las actualizaciones

  1. Agregar vim.pack.add() a init.lua (se admiten varios formatos)
  2. La instalación se procesa automáticamente al reiniciar Neovim
  3. Al llamar a vim.pack.update(), se puede actualizar todo en bloque a la versión más reciente
  • Soporta verificación de actualizaciones, vista previa (basada en LSP) y confirmación/cancelación desde la consola
  1. Si cambia la versión, modificar la especificación de versión en init.lua y luego ejecutar vim.pack.update({ 'nombre-del-plugin' })
  2. El freeze de versión se define con base en el hash del commit actual
  3. La eliminación se realiza llamando a vim.pack.del()

Parámetros y comportamiento principales de la API

  • add: recibe una lista de plugins; si no existen, descarga con git clone y hace checkout de la versión indicada
  • actualización: con la bandera force se puede elegir entre modo inmediato o modo con diálogo de confirmación, y los cambios quedan registrados en nvim-pack.log
  • Se proporcionan hooks para cada evento (instalación/actualización/eliminación) y se expone la metainformación del plugin

Notas

  • En producción, al ser un gestor experimental, puede haber cambios repentinos de comportamiento
  • Aunque el plugin ya exista en disco, la versión real puede no coincidir con la versión especificada, por lo que es indispensable sincronizar con update
  • Al eliminarlo, hay que quitar su especificación de add para evitar que se reinstale

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-09-06
Comentarios en Hacker News

  • Tengo muchísimas ganas de esta actualización; ojalá la comunidad de plugins de nvim evolucione hacia una forma en la que los plugins hagan lazy loading por defecto sin usar un gestor de plugins complejo como lazy. También estaría bueno que revisaran la nota relacionada en la documentación oficial de nvim: documentación oficial de lazy loading de nvim. Personalmente también me gustan mucho las best practices propuestas por el plugin nvim-neorocks: best practices de nvim-neorocks. Parece que recientemente parte de eso se fusionó oficialmente: neovim PR #29073

    • Al usar el modelo setup() en neovim, siento que el lazy loading se volvió más complicado que en Vim tradicional. En Vim, solo configuras variables y el plugin se carga automáticamente cuando se ejecuta la función. En el mundo basado en lua, si varios autocmd hacen referencia al mismo plugin, todos tienen que llamar setup() directamente, así que hace falta un poco más de orquestación

  • Siento que he estado cambiando de gestor de paquetes de (Neo)Vim más o menos cada 3 años; mi recorrido fue pathogen → Vundle → vim-plug → lazy.nvim. Ojalá este sea el último gestor de paquetes de Vim

    • Igual creo que Plug sigue siendo bastante usable. Esta versión integrada, al venir incluida en el lenguaje, me parece una especie de endgame que podría satisfacer a más usuarios. La probé personalmente; no usaba las funciones especiales que ofrecía lazy, pero funcionó bien sin problemas

    • Me da gusto que por fin exista un gestor de paquetes oficial integrado oficialmente. Creo que en adelante será el más soportado y el más usado (aunque claro, puede variar en riqueza de funciones)

    • También creo que lazy.nvim es muy potente. Pero como muchos plugins soportan distintos gestores de paquetes, también hace falta cierto nivel de estandarización. No sé si pueda surgir algo tan rápido y confiable como lazy.nvim, pero tampoco me parece imposible

    • Yo empecé a usar nixvim. Más o menos en la época de vim-plug simplemente me rendí. Era una pesadilla mantener siempre bien la configuración entre varias máquinas y distintos sistemas operativos

    • En Nix siempre funciona de la misma manera. En NixOS, MacOS y Linux con home-manager gestionado por nix se puede configurar así

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

  • Por si le sirve a usuarios de neovim, hace poco migré de lazy.nvim a usar solo vim.pack vean este Pull Request. No tuve ningún problema y uso solo unos 50 plugins. Fue muchísimo más fácil de lo esperado, y con ayuda de un conocido armé una configuración para que los plugins carguen de forma parecida a lazy. En particular, en mi computadora de trabajo la carga de plugins, que con lazy.nvim tomaba 300 ms, ahora bajó hasta 80 ms

    • Como referencia, ese enlace está llevando a archivos no relacionados dentro del diff

  • Cada vez que veo que se puede importar código desde git y hasta especificar rama o hash de commit, me dan ganas de que documenten una función de “checkout de una rama en un momento específico”. Muchas ramas de plugins de Vim ni siquiera hacen versionado. Por ejemplo, se puede hacer checkout para una fecha y hora específica con algo como git checkout 'master@{2025-05-26 18:30:00}'. La idea sería prevenir fallas de versionado como el desastre de leftPad o el incidente de seguridad de xz

    • Suena como una idea interesante, pero me surge la duda de “¿según el reloj de qué momento?”. Importa si es el reloj propio del repositorio, el de mi computadora o el del git remoto. En general, hacerlo por hash es lo correcto, y no recomendaría desarrollo de software basado en tiempo salvo como último recurso

    • Me da curiosidad el riesgo de ataques a la cadena de suministro. Quisiera saber qué nivel de permisos tienen los plugins de VIM

    • Si haces checkout de master en un momento dado, no trae lo que había en ese momento, sino que depende del momento en que haces pull, así que resulta confuso (no es reproducible). Si quieres reproducibilidad real, necesitarías métodos más complejos como git log --before=time y similares

    • Me pregunto si no bastaría simplemente con usar el SHA

  • En realidad no hace falta un gestor de plugins de Vim, sobre todo si manejas tus dotfiles con git. Basta con clonar los archivos del plugin en un directorio determinado, y si también gestionas la configuración con git, puedes rastrear las versiones fijando los plugins con submodules de git. Ese enfoque también favorece el version pinning

    • Yo también usé git submodule durante un año. La motivación era la idea de reemplazar todos los gestores de paquetes específicos de herramientas con submodules (vim, tmux, zsh, etc.). Pero en la práctica administrar submodules era muchísimo más engorroso que usar vim-plug. El concepto es bueno, pero en Git la ergonomía deja mucho que desear, y al final regresé. Si alguien tiene experiencia usando el pack integrado de vim y sintiéndolo incluso más cómodo que vim-plug, me gustaría escucharla

    • Yo necesito activar y desactivar plugins con frecuencia, así que hacerlo por config me resulta más cómodo que usar solo el sistema de archivos. Además, es fácil activar plugins según el tipo de archivo. De hecho, creo que la mayoría de los gestores de plugins al final no son más que wrappers sobre git

  • Todavía está bastante verde. Aun así, si llega el día en que deje lazy, me gustaría que para entonces exista deferred load. lazy.nvim sin duda es excelente, pero últimamente siento que su autor está mostrando cierto comportamiento de lock-in de usuarios al implementar él mismo plugins open source famosos como snack.nvim y mini.nvim. No termino de entender esa estrategia tipo copycat/kill zone

    • Incluso algunos paquetes ni siquiera los mantiene y los deja abandonados (por ejemplo, snacks). Y por cierto, mini.nvim es de un autor completamente distinto; no tiene que ver con lazy

    • Aun así, creo que el autor de lazy sí tiene la capacidad de crear interfaces de gran calidad a su manera. A mí ese estilo me gusta bastante, así que seguido termino pensando que es de lo mejor. El picker de Snacks, por ejemplo, se volvió la mejor opción

  • Llevo mucho tiempo usando vim, pero llegué a la conclusión de que usar neovim con plugins al final no vale tanto la pena. Siempre se rompe algo. Preferiría que plugins clave (LSP, tree sitter) se integraran de forma nativa para que neovim despegara más

    • Yo sentía algo parecido, y para desarrollo en C/C++ me iba bien resistiendo con vim-plug, gutentags (ctags) y ALE. Pero cuando empecé a hacer desarrollo web y tuve que usar varias sintaxis y herramientas, terminé cambiándome a una distro de neovim. Probé varias distribuciones; Lunarvim (ya discontinuado) me funcionó bien y ahora Astronvim también me encaja bastante

    • En realidad, tree-sitter y LSP ya están integrados de forma nativa. Los plugins principales de LSP/tree-sitter básicamente solo aportan configuraciones por defecto y bundles de queries, e incluso hay planes de que neovim empaquete las queries de forma nativa para dejar de depender de nvim-treesitter a futuro. La configuración de LSP también se ha vuelto muy sencilla; por ejemplo

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

      Y también se pueden definir keymaps por LSP en el autocmd de "LspAttach"

    • Mi predicción es que en los próximos 5 a 10 años esto debería acomodarse

  • Llevo bastante tiempo usándolo y no he tenido ningún problema vean mis dotfiles

  • Honestamente, ni siquiera hace falta que sea minimalista; salvo que haya otra razón muy especial, me gustaría que fuera una solución integrada. Ahora mismo uso vim pack junto con git submodule, y me confunde qué proyecto de GitHub es el óptimo/recomendado/mejor soportado, así que no tengo ganas de volver a elegir otro gestor de paquetes para nvim

  • Este es el issue original donde se añadió: issue oficial de neovim #20893. Parece que era un objetivo antiguo del proyecto neovim, aunque no explicaban por qué. Sinceramente me parecía más bien bloat, porque los plugins existentes ya venían haciendo muy bien ese trabajo. Pero parece que no todos estaban de acuerdo