Neovim Pack

(neovim.io)

1 pontos por GN⁺ 2025-09-06 | 1 comentários | Compartilhar no WhatsApp

O Neovim introduziu vim.pack, um gerenciador de plugins experimental integrado, oferecendo de forma unificada instalação, gerenciamento de versões e remoção de plugins sem a necessidade de um gerenciador externo separado
(Como ainda está em fase inicial de testes, a API pode mudar com frequência)

Principais recursos

Gerenciamento dedicado do diretório $XDG_DATA_HOME/nvim/site/pack/core/opt
Os plugins devem obrigatoriamente estar no formato de repositório Git, e o comando git (versão mínima 2.36 ou superior) é obrigatório
A versão do plugin pode ser especificada por tags semver (no formato v1.2.3) ou por branch/hash de commit
Todas as operações, como instalar, atualizar, remover e congelar versão (freeze), são tratadas por funções integradas

Como funcionam a instalação e a atualização

Adicione vim.pack.add() ao init.lua (há suporte a vários formatos)
Ao reiniciar o Neovim, a instalação é processada automaticamente
Ao chamar vim.pack.update(), é possível atualizar tudo em lote para a versão mais recente

Suporte a verificação de atualizações, pré-visualização (baseada em LSP) e confirmação/cancelamento no console

Ao mudar a versão, edite a especificação da versão em init.lua e depois execute vim.pack.update({ 'nome-do-plugin' })
O freeze da versão é definido com base no hash do commit atual
A remoção é feita chamando vim.pack.del()

Principais parâmetros e comportamento da API

add: recebe a lista de plugins e, se não existirem, faz download com git clone e realiza o checkout da versão
atualização: com a flag force, é possível escolher entre modo imediato ou modo com diálogo de confirmação; as mudanças ficam registradas em nvim-pack.log
Hooks são fornecidos em cada evento (instalação/atualização/remoção), expondo metadados do plugin

Observações

Em produção, como é um gerenciador experimental, pode haver mudanças repentinas de comportamento
Mesmo que o plugin já exista em disco, a versão real e a versão especificada podem não coincidir, então a sincronização via update é essencial
Ao remover, é preciso apagar a especificação em add para evitar reinstalação

1 comentários

GN⁺ 2025-09-06

Comentários do Hacker News

Estou bem empolgado com esta atualização; espero que a comunidade de plugins do nvim evolua para carregar plugins de forma lazy por padrão, sem depender do lazy, que é um gerenciador de plugins complexo. Também seria bom consultar a nota na documentação oficial do nvim sobre isso: documentação oficial de lazy loading do nvim. Pessoalmente, gosto bastante das best practices propostas pelo plugin nvim-neorocks: best practices do nvim-neorocks. Parece que parte disso foi incorporada oficialmente recentemente: neovim PR #29073
- No neovim, por causa do modelo setup(), tenho a impressão de que o lazy loading ficou mais complicado do que no Vim tradicional. No Vim, bastava definir variáveis e o plugin era carregado automaticamente quando a função era executada. No mundo baseado em lua, quando vários autocmd referenciam o mesmo plugin, todos precisam chamar setup() diretamente, então acaba sendo necessária um pouco mais de orquestração
Sinto que tenho trocado de gerenciador de pacotes do (Neo)Vim a cada uns 3 anos. Minha jornada foi pathogen → Vundle → vim-plug → lazy.nvim. Espero que este seja o último gerenciador de pacotes do Vim
- Ainda acho o Plug bastante utilizável. Esta versão embutida, por vir integrada à linguagem, parece um endgame capaz de satisfazer mais usuários. Testei pessoalmente; eu não usava os recursos especiais do lazy, mas funcionou bem sem complicação
- Fico feliz que finalmente exista um gerenciador de pacotes oficial e embutido oficialmente. Acho que, daqui para frente, ele tem grandes chances de ser o mais amplamente suportado e usado (embora a riqueza de recursos possa ser diferente)
- Também acho o lazy.nvim muito poderoso. Mas, como vários plugins acabam suportando diferentes gerenciadores de pacotes, sinto que também precisamos de algum nível de padronização. Tenho dúvidas se surgirá algo tão rápido e confiável quanto o lazy.nvim, mas não parece impossível
- Comecei a usar nixvim. Na época do vim-plug eu simplesmente desisti. Era um sofrimento manter a configuração sempre funcionando bem em várias máquinas e diferentes sistemas operacionais
- No Nix, tudo funciona sempre do mesmo jeito. Em NixOS, MacOS e no home-manager gerenciado por nix no Linux, dá para configurar assim
```
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;
}
```
Caso isso ajude usuários de neovim, recentemente migrei do lazy.nvim para uma configuração usando apenas vim.pack: veja este Pull Request. Não tive nenhum problema e uso só cerca de 50 plugins. Foi muito mais fácil do que eu esperava, e com a ajuda de um conhecido montei uma configuração em que os plugins carregam de forma parecida com o lazy. Especialmente no meu computador de trabalho, o carregamento de plugins que levava 300ms com lazy.nvim agora caiu para 80ms
- Só como observação, esse link está levando para arquivos não relacionados no diff
Sempre que vejo que dá para importar código do git e até especificar branch ou hash de commit, eu gostaria que houvesse documentação sobre a funcionalidade de “checkout de branch em um ponto específico no tempo”. Muitos branches de plugins do Vim nem fazem versionamento direito. Por exemplo, dá para fazer checkout com base em uma data e hora específicas usando algo como git checkout 'master@{2025-05-26 18:30:00}'. A ideia é evitar problemas de versionamento como o desastre do leftPad ou o incidente de segurança do xz
- Parece uma ideia interessante, mas fico com a dúvida: “com base no relógio de qual momento?”. O relógio do próprio repositório, o do meu computador ou o do git remoto? Em geral, usar hash é o correto, e eu não recomendaria desenvolvimento de software baseado em tempo, exceto como último recurso
- Tenho curiosidade sobre o risco de ataques à cadeia de suprimentos. Gostaria de saber que nível de permissões os plugins do VIM têm
- Se você fizer checkout do master em um momento específico, não é como se você estivesse baixando exatamente aquele estado naquele momento; acaba dependendo do momento em que você faz o pull, o que gera confusão (sem reprodutibilidade). Se quiser reprodutibilidade de verdade, precisa de algo mais complexo, como git log —before=time
- Será que simplesmente usar SHA não resolveria?
Um gerenciador de plugins do Vim não é estritamente necessário, especialmente se você já gerencia seus dotfiles com git. Basta clonar os arquivos dos plugins no diretório apropriado. Se a configuração também for gerenciada com git, dá para rastrear e fixar as versões dos plugins com submodules do git. Essa abordagem também é boa para version pinning
- Eu também usei git submodule por um ano. A motivação era a ideia de que eu poderia substituir todos os gerenciadores de pacotes específicos de ferramentas por submodules (vim, tmux, zsh etc.). Mas, na prática, administrar submodules era bem mais trabalhoso do que usar vim-plug. O conceito é bom, mas a ergonomia no Git deixa a desejar, e no fim eu voltei atrás. Se alguém tiver experiência usando o vim pack embutido de um jeito ainda mais confortável que o vim-plug, gostaria de ouvir
- Eu preciso ativar e desativar plugins com frequência, então fazer isso via config é mais prático do que com um sistema simples de arquivos. Além disso, é fácil ativar plugins por tipo de arquivo. Na verdade, acho que a maioria dos gerenciadores de plugins acaba sendo só um wrapper em torno do git
Ainda está em um estado meio primitivo. Mas, se algum dia eu abandonar o lazy, espero que exista suporte a deferred load. O lazy.nvim é claramente excelente, mas ultimamente sinto que o autor vem implementando por conta própria vários plugins open source famosos, como snack.nvim e mini.nvim, o que me passa uma sensação de lock-in de usuário. Não entendo essa estratégia de copiar/ocupar espaço de outros
- Alguns pacotes nem chegam a ser mantidos e ficam abandonados (por exemplo, snacks). E, só para constar, mini.nvim é de um autor completamente diferente; não tem relação com o lazy
- Ainda assim, acho que o autor do lazy tem uma grande capacidade de criar interfaces de qualidade do jeito dele. Eu gosto bastante desse estilo e frequentemente acabo achando que é o melhor. O picker do Snacks, por exemplo, acabou virando a melhor opção
Sou usuário antigo de vim, mas concluí que usar neovim com plugins no fim das contas não é tão bom assim. Sempre tem alguma coisa quebrando. Acho que o neovim se sairia melhor se integrasse nativamente os plugins essenciais (LSP, tree sitter)
- Tive a mesma sensação e consegui me virar bem para desenvolvimento em C/C++ usando vim-plug, gutentags (ctags) e ALE. Mas, quando comecei a fazer desenvolvimento web com várias sintaxes e ferramentas, acabei migrando para uma distro de neovim. Testei várias distribuições; a Lunarvim (hoje descontinuada) funcionou bem para mim, e atualmente uso Astronvim
- Na verdade, tree-sitter e LSP já são integrados nativamente. Os principais plugins de LSP/tree-sitter basicamente fornecem configurações padrão e bundles de queries, e no futuro há planos para o neovim incluir essas queries nativamente também, sem depender de nvim-treesitter. A configuração de LSP também ficou bem simples; por exemplo:
```
vim.lsp.config("expert", {
  cmd = { "expert" },
  root_markers = { "mix.exs", ".git" },
  filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")
```
  E também dá para definir keymaps específicos de cada LSP no autocmd "LspAttach"
- Minha previsão é que isso deva se ajeitar nos próximos 5 a 10 anos
Uso isso há bastante tempo e não tive problema nenhum: veja meus dotfiles
Sinceramente, nem precisa ser minimalista a esse ponto; a menos que haja algum motivo muito específico, eu preferiria que fosse uma solução integrada. Hoje uso vim pack junto com git submodule, mas fico confuso sobre qual projeto do GitHub é o ideal/recomendado/bem suportado, e não quero ter que escolher outro gerenciador de pacotes do nvim de novo
Esta é a issue original em que isso foi adicionado: issue oficial do neovim #20893. Parece que era um objetivo antigo do projeto neovim, mas não havia explicação do porquê. Sinceramente, como os plugins existentes já vinham fazendo um ótimo trabalho, isso me pareceu meio bloat. Mas aparentemente nem todo mundo concordou
- A explicação está na própria issue, vale dar uma olhada: a explicação dessa issue

Neovim Pack

Principais recursos

Como funcionam a instalação e a atualização

Principais parâmetros e comportamento da API

Observações

Leituras relacionadas

1 comentários

Comentários do Hacker News