Denops moves Vim plugin development onto Deno and TypeScript

A plugin ecosystem that runs on Deno instead of Vimscript

Denops, pronounced dee-nops, is an ecosystem for Vim and Neovim that lets developers write plugins in TypeScript or JavaScript powered by Deno. The problem it addresses is well known to anyone who has shipped a Vim plugin: Vimscript is a small language with a long history, and it is not the language most people reach for when they want modern tooling, typed code, or the ability to depend on JavaScript packages. Denops answers that by putting a Deno runtime behind the editor, so plugin code is ordinary TypeScript or JavaScript running in a modern runtime, and the same plugin can then be used across platforms rather than being tied to one editor build. The trade-off is stated plainly in the documentation: Denops requires a Deno process to start before anything works, and that startup can become a bottleneck. This is an ecosystem for plugin authors who accept a runtime dependency in exchange for the language, not a drop in replacement for writing Vimscript.

Where the bridge lives in the repository

The repository layout shows how the pieces fit together. There is an autoload directory, which is where Vim's own autoload mechanism lives, and a plugin directory for the files loaded at startup. The Deno side sits in the denops directory, and it includes a @denops-private area whose cli.ts script is the entry point used to launch a shared server manually. A deno.jsonc file at the top level holds the Deno project configuration, which is where a Deno developer's expectations of module resolution and tooling live. Alongside that there is a doc directory with denops.txt, the Vim help file, so the project follows Vim convention and ships real help text rather than only online documentation. Tests and helper scripts sit in tests and .scripts. Nothing here needs a C compiler or a native build step, which is one of the practical benefits of basing the ecosystem on a runtime that ships as a single executable.

Installing Deno, the plugin and a hello world check

The setup order matters, because Denops cannot run without Deno present. First install the latest Deno, following the official installation manual, and make sure the deno command is executable from the editor. The documentation shows how to confirm that with Vim's own exepath function:

:echo exepath('deno')
/usr/local/bin/deno

If the executable is not on the path the editor sees, point Denops at it directly with the g:denops#deno variable:

let g:denops#deno = '/usr/local/bin/deno'

Then install vim-denops/denops.vim as an ordinary Vim plugin, for example with vim-plug:

Plug 'vim-denops/denops.vim'

To prove the whole chain works, the documentation asks you to install the companion plugin vim-denops/denops-helloworld.vim and run its command:

:DenopsHello
Hello

Seeing Hello means the Deno process launched, the plugin was found and the bridge is talking. You can remove the hello world plugin afterwards. The documentation lives at the Denops documentation site and the Vim help file, and plugin authors are pointed at real Denops plugins such as skkeleton, ddu.vim and gin.vim as reading examples.

The shared server removes the per-plugin startup tax

Here is the real cost of the design. Because each Denops plugin normally needs a Deno process to start, opening the editor with several Denops plugins installed can be slow, and the documentation calls this out as the main usability problem. The fix is a shared server, one Deno process that several plugins connect to instead of each starting its own. You opt in by setting the server address in your configuration:

let g:denops_server_addr = '127.0.0.1:32123'

The shared server itself is a separate plugin, vim-denops/denops-shared-server.vim, installed the same way as any other, and then set up with a single call:

:call denops_shared_server#install()

If you would rather manage the process yourself, the documentation gives the underlying command, which runs the cli.ts script from the denops directory and listens on the address you configured:

deno run -A --no-lock {path/to/denops.vim}/denops/@denops-private/cli.ts --hostname=127.0.0.1 --port=32123

After that, restarting the editor shows the improvement in plugin startup time. Note that the manual command passes the -A flag, which grants the Deno process broad permissions, so anyone running it should understand what that allows before copying it into a startup script.

Windows Defender scanning the Deno cache

There is a second, more specific failure mode in the documentation, and it only appears on Windows. Even with the shared server in place, plugins can still start slowly, and the explanation given is antivirus software. Windows Defender, and other antivirus products, scan the Deno cache directory, given as %LOACALAPPDATA%\deno, every time Deno starts, and that scan is expensive enough to show up as plugin latency. The documented remedy is to add the Deno cache directory to the antivirus exclusion list, with the Microsoft support page on adding an exclusion to Windows Security referenced for the steps, and the documentation asks you to do this with your own responsibility. It is worth being blunt about the trade-off: the advice is to stop scanning the directory where an executable runtime keeps its downloaded artifacts, which is a security decision rather than a configuration tweak. Teams with locked down endpoint policies may simply not be able to take the advice, and for them the shared server still helps because it reduces how often Deno starts at all.

Version floors, the support policy and the MIT licence

Denops states minimum versions up front: Deno 2.3.0 or above, Vim 9.1.1646 or above, and Neovim 0.11.3 or above. The support policy is written in terms of releases rather than fixed numbers. For Vim, support covers versions older than the latest version provided by Homebrew and the version distributed by the vim-win32-installer, so Windows and macOS users are effectively held at the newest packaged Vim and Linux users can build whatever they prefer. For Neovim and Deno, support extends to the two most recent minor versions, on the grounds that both follow semantic versioning. The reasoning about Neovim is worth noting: because it is still in the 0.x range, the project treats the 0.x.y version as part of the 0.x version, so a 0.11.x release counts as current. Released versions include v8.0.0 on 2025-08-24, v8.0.1 on 2025-10-26 and v8.0.2 on 2026-03-22, and the last push was on 2026-10-13. The code is MIT licensed, which keeps the licensing question simple for plugin authors who want to publish their work.

Editorial conclusion

Adopt Denops if you are writing a Vim or Neovim plugin and want TypeScript, cross-platform behaviour and the wider JavaScript ecosystem, and if you are willing to run a Deno process alongside the editor. Do not adopt it for a plugin that must load instantly on editor start, since Deno startup is the acknowledged bottleneck, and do not skip the shared server if you ship several Denops plugins. Before you commit, confirm that your Deno, Vim and Neovim versions are inside the supported ranges, that the deno command is reachable from the editor through exepath, and that a shared server on 127.0.0.1:32123 is acceptable in your environment.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vim-denops/denops.vim on GitHub