VAM manages Vim plugins as a declared list, with dependencies and lazy loading

Plugins are named, and names resolve through vim-pi or a URL

The project starts from a definition of what a plugin is, which is worth reading because it explains the whole design. A plugin is a set of files having Vim's runtimepath directory layout, with plugin/, ftplugin/ and similar directories, and it is identified by a name which will be looked up by vim-pi or a URL such as a git URL or a github user and repository pair. So the unit of management is a name, not a path on disk, and the resolution of a name to a checkout is delegated to vim-pi, an older Vim plugin index. Plugin names can be found through the c-x c-p completion in .vim files, and the VAMActivate and VAMPluginInfo commands also offer name completion by tab or c-d. In most cases you activate plugins by using their name, and wrapping the name in a dictionary allows attaching additional information which could be used by checkout functions, which is the hook the lazy loading feature uses.

Three lines is a working setup

The minimal setup is three lines, and the README presents it as the starting point rather than a simplified example. You set the compatibility options, append the VAM directory to the runtimepath and call the activation function with a list of plugin names:

set nocompatible | filetype indent plugin on | syn on
set runtimepath+=/path/to/vam
call vam#ActivateAddons([PLUGIN_NAME])

@@C1@@That is the whole activation path. The recommended setup is longer because it also handles the checkout, and it is written as a function you call from your vimrc, with the plugin root directory defaulting to a vim-addons directory under your home directory, an option to force the after directory in the runtimepath to be last, and switches for logging to a buffer and for automatic installation. The function clones the repository with a shallow clone if the directory does not already exist, and then calls the activation function with an empty list and an empty options dictionary, which brings in everything declared. A point worth noting is that this setup does the checkout at startup, so a machine with a slow or absent network pays for it on every launch unless auto-install is turned off.

Commands cover install, update, list and uninstall

The command set is the practical surface of the tool, and the README notes that all commands support completion with c-d or tab. VAMInstall installs plugins without activating them, so you can review them first, and the optional E flag means the directory is only created if it does not already exist. VAMActivate installs and activates, and VAMActivateInstalled does the same with completion limited to installed plugins. VAMPluginInfo finds plugins by name, GitHub URL or script id and displays all information about them. VAMUpdate updates plugins by name or all the ones you are currently using, with a note that you should restart Vim afterwards, and VAMUpdateActivated updates only what is active. There is VAMListActivated to show what is loaded and VAMUninstallNotLoadedPlugins to remove the ones that are not currently in use. The distinction between installed and activated is the concept the whole manager is built on, and it is also what makes lazy loading possible.

Dependencies come from addon-info.json, and only mandatory ones are forced

The dependency question has its own section, and the answer is a metadata file rather than a resolution algorithm. Plugins ship with addon-info.json files listing the dependencies as names, eventually with a source location, and those that are not patched by vim-pi go unhandled. The rule the README states is that only mandatory dependencies should be forced this way, and that optional dependencies should still be installed and activated by you. That is a sensible division of labour for a manager that cannot ask the user anything at install time, but it means the dependency graph is only as good as the metadata that plugin authors ship, and a missing or stale addon-info.json produces a plugin that activates with half of its requirements absent. The metadata file also exists at the root of the VAM repository itself, for the manager's own dependencies.

Declarative lists enable lazy loading and a garbage collector

The lazy loading mechanism is a list of dictionaries rather than a name list, and the keys are what carry the meaning. A script can be matched by a filename regular expression when its filetype is only known after the script runs, or by a filetype regular expression, and it can carry an exec key with an arbitrary command, or an activate_this_rtp key pointing at an absolute runtimepath to add, or an addon-info key with a runtimepath entry to set. Each script can carry a tag, and the activation call takes a tag_regex to select which tagged scripts to activate immediately:

call add(scripts, {'names': ['plugin_for_c_1', 'plugin_for_c_2'], 'tag': 'c-dev'})
call add(scripts, {'name': 'plugin_ruby', 'tag': 'ruby-dev'})
" must activate by filename because .pov filetype is known after the script
" script-povray got activated
call add(scripts, {'name': 'script-povray', 'filename_regex':'\.pov$'})
" for others ft_regex can be used:
call add(scripts, {'name': 'script-php', 'ft_regex':'^\.php$'})

" always activate this color scheme, and set runtimepath
call add(scripts, {'name': 'github:daylerees/colour-schemes', 'addon-info': {'runtimepath': 'vim'} })

" just activate a rtp (also works at runtime with all hooks such as sourcing ftdetect/*.vim files)
call add(scripts, {'activate_this_rtp': 'absolute-rtp-path'})


" tell VAM about all scripts, and immediately activate plugins having the c-dev tag:
call vam#Scripts(scripts, {'tag_regex': 'c-dev'})

@@C2@@The reason this matters is stated further down. Having a declarative list of plugins you might be using allows implementing a garbage collector, implementing third party update and checkout scripts which run checkout in parallel, and reusing such an interface by other plugin managers. That last point is the interesting one, because it is what makes the manager composable with something like lazy.nvim rather than merely competing with it.

It emulates vundle deliberately, and coexists with lazy.nvim

Two sections address the ecosystem question, and both are honest about the competition. The vundle emulation section notes that VAM is declarative, so Bundle behaves like VAMActivate, checking out the plugin unless the directory exists and then activating it, and the README asks pointedly why you would run BundleInstall at all. The vundle config is set up in two lines, with the runtimepath appended and vundle#rc() called, and then plugin names are given as Bundle entries. The Neovim section says that VAMActivate after startup does load plugin/**/*.lua files, that lazy.nvim might be worth looking at too, and points at a document called CO_EXISTING_WITH_LAZY_NVIM.md for using both. The repository also has a compat-layer-lazy-nvim-use-vam/ directory, so coexistence is a supported scenario rather than a warning. The plugin name completion also knows about plugins that are neither on vim-scripts.org nor on vim.sf.net, which the screenshot marks as NA.

A small project with a Windows downloader and a custom licence

The repository contents show a project that is small but has thought about the edges. There is an autoload/ directory for the Vim Script functions, a downloader/ directory with an installer that the README recommends to Windows users who are too lazy to install the supporting tools, and it notes that https with a self signed certificate can be used too. There is a doc/ directory for the additional documentation, a test/ directory and a vim-addon-manager-test.sh script at the root, and the CO_EXISTING_WITH_LAZY_NVIM.md file. The licence is recorded as a custom licence that GitHub cannot classify, with the LICENSE.txt file at the root, and there is no GitHub release history, so the only way to track versions is the commit log. The README says the project is well supported by at least two maintainers and asks for GitHub tickets or the Vim IRC channel on freenode, and the repository description adds that the author usually replies within 24 hours.

Editorial conclusion

VAM suits a Vim user who wants a declarative plugin list, dependency handling and lazy loading without leaving Vim Script, and who is comfortable editing a vimrc function rather than running a bootstrap script. It does not suit a Neovim user on lazy.nvim, since the README's own guidance is that lazy.nvim might be worth looking at and a dedicated document covers coexisting with it. Before adopting, read the compatibility notes and the declarative list section, and note that the last push to the repository was on 2026-05-09 with no GitHub releases published and a custom licence file at the root.

Frequently asked questions

Official sources

1. Issues
2. MarcWeber/vim-addon-manager on GitHub
3. README