Neovim Pack

• Neovim introduit vim.pack, un gestionnaire de plugins intégré expérimental, qui regroupe l’installation, la gestion des versions et la suppression des plugins sans gestionnaire externe séparé
• (Comme il s’agit d’une phase de test initiale, l’API peut changer fréquemment)

Principales caractéristiques

• Gestion dédiée du répertoire $XDG_DATA_HOME/nvim/site/pack/core/opt
• Les plugins doivent obligatoirement être au format dépôt Git, et la commande git est requise (version minimale 2.36)
• La version d’un plugin peut être définie via un tag semver (forme v1.2.3), ou par branche / hash de commit
• Toutes les opérations, comme l’installation, la mise à jour, la suppression et le gel de version (freeze), sont gérées via des fonctions intégrées

Fonctionnement de l’installation et des mises à jour

1. Ajouter vim.pack.add() à init.lua (plusieurs formats pris en charge)
2. L’installation est effectuée automatiquement au redémarrage de Neovim
3. En appelant vim.pack.update(), il est possible de mettre à jour l’ensemble vers la dernière version

• Vérification des mises à jour, aperçu (basé sur LSP), prise en charge de la confirmation / annulation dans la console

4. Lors d’un changement de version, modifier la version indiquée dans init.lua, puis exécuter vim.pack.update({ 'nom_du_plugin' })
5. Le freeze de version s’effectue sur la base du hash de commit actuel
6. La suppression se fait via l’appel à vim.pack.del()

Principaux paramètres et comportements de l’API

• add : reçoit une liste de plugins ; s’ils n’existent pas, téléchargement via git clone puis checkout de la version
• Mise à jour : le drapeau force permet de choisir entre exécution immédiate et mode avec dialogue de confirmation ; les changements sont consignés dans nvim-pack.log
• Des hooks sont fournis pour chaque événement (installation / mise à jour / suppression), avec exposition des métadonnées du plugin

À noter

• En production, comme il s’agit d’un gestionnaire expérimental, des changements brusques de comportement peuvent survenir
• Même si un plugin est déjà présent sur le disque, la version réelle peut ne pas correspondre à la version spécifiée ; une synchronisation via update est donc nécessaire
• Lors d’une suppression, il faut retirer la spécification de add pour éviter une réinstallation

[GN⁺]

Avis Hacker News

• J’attends vraiment beaucoup cette mise à jour, et j’aimerais que la communauté des plugins nvim évolue vers un chargement paresseux des plugins par défaut sans passer par un gestionnaire de plugins complexe comme lazy. Il y a aussi une note à ce sujet dans la documentation officielle de nvim, donc ça vaut le coup d’y jeter un œil : documentation officielle du lazy loading de nvim. Personnellement, j’aime aussi beaucoup les bonnes pratiques proposées par le plugin nvim-neorocks : nvim-neorocks best practices. Il semble qu’une partie de cela ait récemment été fusionnée officiellement : neovim PR #29073

  • Avec le modèle setup() dans neovim, j’ai l’impression que le lazy loading est devenu plus délicat qu’avec l’ancienne approche Vim. Dans Vim, il suffit de définir des variables et le plugin se charge automatiquement quand la fonction est appelée. En Lua, si plusieurs autocmd référencent le même plugin, il faut appeler setup() explicitement pour chacun, donc il y a un peu plus d’orchestration à faire

• J’ai l’impression de changer de gestionnaire de paquets (Neo)Vim tous les trois ans environ, mon parcours a été pathogen → Vundle → vim-plug → lazy.nvim. J’espère que ce sera mon dernier gestionnaire de paquets Vim

  • Je pense que Plug reste tout à fait utilisable. Cette version intégrée me semble être une sorte d’endgame capable de satisfaire davantage d’utilisateurs parce qu’elle est embarquée dans le langage. Je l’ai essayée moi-même ; je n’utilisais pas les fonctions spéciales fournies par lazy, mais dans l’ensemble ça a très bien marché

  • Je suis ravi qu’il y ait enfin officiellement un gestionnaire de paquets officiel intégré. À l’avenir, c’est probablement celui qui sera le plus largement pris en charge et utilisé (même si la richesse fonctionnelle peut différer)

  • Je pense aussi que lazy.nvim est très puissant. Mais comme de nombreux plugins prennent chacun en charge plusieurs gestionnaires de paquets, un certain degré d’uniformisation est nécessaire. Je me demande s’il est possible d’avoir quelque chose d’aussi rapide et fiable que lazy.nvim, mais ça ne me semble pas impossible

  • J’ai commencé à utiliser nixvim. J’avais plus ou moins abandonné vers l’époque de vim-plug. Garder une configuration toujours propre sur plusieurs machines et différents OS était pénible

  • Avec Nix, ça fonctionne toujours de la même façon. On peut configurer ainsi sur NixOS, MacOS, Linux avec home-manager géré par Nix

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

• Au cas où cela pourrait aider des utilisateurs de neovim, j’ai récemment migré de lazy.nvim vers une utilisation exclusive de vim.pack : voir cette Pull Request. Je n’ai eu aucun problème et je n’utilise qu’une cinquantaine de plugins. C’était bien plus simple que prévu, et avec l’aide d’une connaissance j’ai mis en place une configuration où les plugins se chargent un peu comme avec lazy. Surtout, sur mon ordinateur de travail, le chargement des plugins qui prenait 300 ms avec lazy.nvim est maintenant descendu à 80 ms

  • À noter que ce lien pointe actuellement vers des fichiers sans rapport dans le diff

• Chaque fois que je vois qu’on peut importer du code depuis git et même spécifier une branche ou un hash de commit, j’aimerais qu’il existe une documentation sur la fonctionnalité « checkout d’une branche à un instant donné ». Beaucoup de branches de plugins Vim ne sont même pas versionnées. Par exemple, on peut faire quelque chose comme git checkout 'master@{2025-05-26 18:30:00}' pour revenir à l’état correspondant à une date et une heure précises. L’idée, c’est d’éviter les échecs de gestion de versions du type leftPad ou l’incident de sécurité xz

  • L’idée est intéressante, mais je me demande : « par rapport à quelle horloge ? » Celle du dépôt, de mon ordinateur ou du git distant ? En général, utiliser un hash est la bonne approche, et je ne recommande pas le développement logiciel basé sur le temps sauf en tout dernier recours

  • Je me demande quel est le niveau de risque vis-à-vis des attaques sur la supply chain. J’aimerais savoir quelles permissions ont réellement les plugins VIM

  • Si on checkout le master d’un moment donné, ce n’est pas à ce moment-là qu’on le récupère, mais au moment où je fais le pull, ce qui devient confus (et non reproductible). Si on veut une vraie reproductibilité, il faut des méthodes plus complexes avec git log —before=time et compagnie

  • Je me demande pourquoi ne pas simplement utiliser le SHA

• Un gestionnaire de plugins Vim n’est pas indispensable, surtout si on gère ses dotfiles avec git. Il suffit de cloner les fichiers des plugins dans le répertoire prévu à cet effet. Si la configuration est aussi gérée avec git, on peut suivre et figer les versions des plugins avec des sous-modules git. Cette approche est aussi avantageuse pour le version pinning

  • Moi aussi j’ai utilisé les sous-modules git pendant un an. L’idée de départ, c’était qu’on pourrait remplacer tous les gestionnaires de paquets spécifiques à un outil par des sous-modules (vim, tmux, zsh, etc.). Mais en pratique, la gestion des sous-modules était bien plus pénible que vim-plug. Le concept est bon, mais l’ergonomie de Git laisse à désirer, donc je suis finalement revenu en arrière. Si quelqu’un a une expérience montrant qu’utiliser le vim pack intégré est encore plus confortable que vim-plug, je veux bien la lire

  • J’ai souvent besoin d’activer et de désactiver des plugins, donc faire ça dans la config est plus pratique qu’avec un simple système de fichiers. Et il est facile d’activer les plugins selon le type de fichier. En réalité, je pense que la plupart des gestionnaires de plugins ne sont au fond que des wrappers autour de git

• C’est encore dans un état assez primitif, mais si un jour j’abandonne lazy, j’aimerais qu’un deferred load soit implémenté. lazy.nvim est clairement excellent, mais récemment j’ai l’impression que son auteur a adopté une logique de verrouillage utilisateur en réimplémentant lui-même plusieurs plugins open source connus comme snack.nvim et mini.nvim. Je ne comprends pas cette stratégie de copie / kill zone

  • Certains paquets ne sont même pas maintenus et sont laissés à l’abandon (par exemple : snacks). À noter que mini.nvim a un auteur complètement différent, sans lien avec lazy

  • Malgré tout, je pense que l’auteur de lazy a un vrai talent pour concevoir des interfaces de qualité à sa manière. J’aime beaucoup cette approche, au point de la trouver souvent meilleure. Le picker de Snacks en est un bon exemple, c’est devenu pour moi la meilleure option

• Je suis un vieil utilisateur de vim, mais j’ai fini par conclure que l’usage de plugins dans neovim n’était pas si convaincant. Il y a toujours quelque chose qui casse. Je pense que neovim s’en sortirait mieux si des plugins essentiels comme LSP et tree sitter étaient intégrés nativement

  • J’ai eu le même ressenti, et pour le développement C/C++, je m’en suis bien sorti avec vim-plug, gutentags (ctags) et ALE. Mais en passant au développement web, avec plein de syntaxes et d’outils différents, j’ai fini par migrer vers une distro neovim. J’en ai essayé plusieurs ; Lunarvim (désormais abandonné) et aujourd’hui Astronvim me conviennent bien

  • En réalité, tree-sitter et LSP sont déjà intégrés nativement. Les principaux plugins LSP/tree-sitter ne fournissent surtout que des configurations par défaut et des bundles de requêtes, et à l’avenir neovim prévoit même d’embarquer nativement les requêtes elles-mêmes afin de ne plus dépendre de nvim-treesitter. Configurer LSP est aussi devenu très simple, par exemple

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

    Et on peut aussi définir des raccourcis spécifiques à chaque LSP dans l’autocmd "LspAttach"

  • À mon avis, tout cela finira par se stabiliser dans les 5 à 10 prochaines années

• Je l’utilise depuis assez longtemps et je n’ai eu absolument aucun problème : voir mes dotfiles

• Honnêtement, il n’est pas nécessaire que ce soit minimaliste à tout prix ; sauf raison particulière, j’aimerais surtout une solution intégrée. En ce moment, j’utilise vim pack avec des sous-modules git, mais je suis perdu entre les projets GitHub présentés comme optimaux, recommandés ou bien pris en charge, et je n’ai pas envie d’avoir à choisir encore un autre gestionnaire de paquets nvim

• Voici l’issue d’origine où cela a été ajouté : issue officielle neovim #20893. Cela semble avoir été un objectif de longue date du projet Neovim, mais il n’y avait pas d’explication sur le pourquoi. Honnêtement, comme les plugins existants faisaient déjà très bien le travail, ça m’a paru être du bloat. Mais certains n’étaient visiblement pas d’accord

  • Il y a bien une explication dans cette issue, ça vaut le détour : explication dans cette issue