dvpm

What dvpm is

dvpm is a plugin manager for Vim and Neovim that runs on top of denops.vim, a layer that lets editor plugins be written in Deno based TypeScript. The headline benefit is startup speed: every plugin is loaded lazily, so the editor opens quickly even with a large configuration. The other appeal is that the entire setup, not just the plugins, can be expressed in TypeScript rather than Vimscript or Lua. That gives type checking and familiar syntax to anyone comfortable in the JavaScript ecosystem. The project requires Deno, a modern runtime for TypeScript and JavaScript, as the execution engine behind denops.vim. With 24 stars, dvpm is a focused tool for users who already live in the denops world and want their editor configuration to feel like application code. The license is MIT. Because denops.vim does the heavy lifting of bridging Deno and the editor, dvpm can stay small and concentrate on the plugin lifecycle, which keeps the manager itself easy to reason about and extend. The README shows a startup time screenshot as evidence that lazy loading keeps the editor responsive, and the project page on the JSR registry hosts the published package that users install. The README shows a startup time screenshot as evidence that lazy loading keeps the editor responsive, and the project page on the JSR registry hosts the published package that users install into their Deno environment.

Defining plugins in TypeScript

Plugins are declared in a main.ts file through a small API. Dvpm.begin opens a session with a base path and options such as concurrency, which defaults to eight parallel processes, and Dvpm.end finalizes the list and adds plugins to the runtime path. Each Dvpm.add call takes a URL in GitHub shorthand or a full git URL, and supports a branch or revision, a custom clone path, shallow clone depth, and conditional enabling through a function. Dependencies are listed explicitly so they load first, and lifecycle hooks run init before the runtime path is set, before and after around the plugin source step, and build after install or update. The Plug type is rich: it carries status fields like isInstalled and isUpdated that callbacks can inspect, so a build step can skip heavy work when nothing changed. A plugin can also be enabled based on a profile, disabled conditionally, or loaded from a separate file, which keeps a large configuration organized across many small modules rather than one giant block. The API reference in the README documents every field of the Plug, Lazy, and Bool types, so a user can wire advanced triggers without reading the source. The API reference in the README documents every field of the Plug, Lazy, and Bool types, so a user can wire advanced triggers without reading the source, and the examples cover both Vim and Neovim setup paths.

Commands, caching, and lazy loading

Daily use flows through a few commands and features. DvpmUpdate pulls all plugins or a named one, DvpmList shows them in a dedicated buffer, and DvpmCheckHealth runs a health check, with a Neovim only variant under checkhealth. DvpmProfile reports per plugin load time across init, before, load, after, and build phases when profiling is enabled. Caching can write a script so plugins load before VimEnter for an even faster start, and the cache file is generated on first run. Lazy loading is inherent, with explicit triggers on command, event, file type, colorscheme, or keyboard shortcut, and library plugins can stay dormant until a dependent plugin fires. Profiles let a user enable only a subset of plugins, such as a minimal set on a weak machine. Autocommand events expose the lifecycle for custom automation. The combination targets editors that stay responsive under heavy configuration, and the documented examples show how to wire real plugins such as coc.nvim and a keymap plugin into the same declarative file. The hook execution order is fixed and documented, so a user can predict exactly when an init, before, after, or build step runs during a session. The hook execution order is fixed and documented, so a user can predict exactly when an init, before, after, or build step runs, and profiles let a minimal set load on a weak machine while a full set loads on a strong one.

Editorial conclusion

dvpm is distributed under the MIT license, requires Deno as its runtime, and defaults to eight concurrent processes when adding or updating plugins.