The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
packspec
Posts with mentions or reviews of packspec.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-02-10.
- This Week In Neovim #31 – Mon Feb 13 2023
-
Introducing Luarocks-Tag-Release - Publish your Neovim plugins to LuaRocks
It looks like there's a WIP package specification that might also support source = luarocks://.
-
Standardizing Neovim package management API - could or should this be a thing? Let’s talk about it!
I was hoping you would clarify exactly what you're proposing so I could forward the appropriate link, otherwise I'm just guess based off a vague (but long) post. Based on other replies in this reddit post, I'm not the only one confused by your ambiguous and likely incorrect terminology. It sounds like you're looking for a specification, which exists https://github.com/nvim-lua/nvim-package-specification, it just isn't well adopted. There's also countless Github issues and discussions about this on IRC which you could find by a simple Google search. It really just depends on what you're alluding to which is why I linked what an API was so you could be more specific. If you're looking for the plugin managers API (notice the qualifier) to be consistent, then that's not a good idea since the API of the plugin manager is what differentiates them, it's like saying all programming languages should be the same, the only thing different should be the backend (e.g. gcc vs llvm). The consistency should be at a different layer (thus the plugin spec).
-
Breaking changes inbound (next few weeks) for lspconfig and neovim's language server client lsp
packspec, a package specification for neovim to address the dependency issue
-
Opinion on better plugin management?
There is an issue for it: https://github.com/nvim-lua/nvim-package-specification/issues/23
fabn
Posts with mentions or reviews of fabn.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2022-03-28.
-
Opinion on better plugin management?
I started this https://github.com/bageljrkhanofemus/fabn with the aim to improve neovim plugin specification
What are some alternatives?
When comparing packspec and fabn you can also consider the following projects:
lazy.nvim - 💤 A modern plugin manager for Neovim
nvim-conf - ☄ Maddison's Neovim configuration!
luarocks - LuaRocks is the package manager for the Lua programming language.
vscode-eslint - VSCode extension to integrate eslint into VSCode
lsp-format.nvim - A wrapper around Neovims native LSP formatting.
neovim - Vim-fork focused on extensibility and usability
nvim-lspconfig - Quickstart configs for Nvim LSP