denops.vimとは｜DenoでVim/Neovimプラグインを書く仕組みと始め方

denops.vimは、JavaScript/TypeScriptランタイムのDenoを使って、VimとNeovimの両方で動くプラグインを開発するためのエコシステムです。この記事では、denops.vimの定義と内部構造、Vim script・Lua・coc.nvimとの比較、Denoのインストールからプラグイン登録までの導入手順、main.tsとdenops_stdを使った開発の実務、そしてDenoのバージョン固定や代表的なdenops製プラグインまでを体系的に解説します。Vim scriptに馴染めない方や、TypeScriptの資産を活かしてエディタ拡張を作りたい方が、自分のプロジェクトに採用すべきかを判断できる状態を目指します。

denops.vim導入判断の要点｜Deno基盤でVim・Neovim両対応を実現する選択肢（まとめ）

結論として、denops.vimは「Vim/Neovim両対応のプラグインを、Vim scriptではなくTypeScriptで書きたい」場合に有力な選択肢です。エディタとは別にDenoプロセスを常駐させ、channelというRPCの仕組みで連携するため、JavaScript/TypeScriptの型と補完、Deno標準ライブラリやnpm資産をそのまま活用できます。VimのVim9 scriptとNeovimのLua移行で両者の差が広がるなか、単一コードベースで両対応できる点が最大の利点です。

一方で、利用者の環境にDenoのインストールが必須になること、別プロセス起動のオーバーヘッドと非同期前提の設計が必要になることはトレードオフです。Neovim専用で速度を最優先するならLua、既存のNode.js資産を流用するならcoc.nvimという判断もあり得ます。採用するなら、Denoのバージョンとキャッシュ位置を固定し、ddu.vimやgin.vimといった実績あるプラグインの構成を参考に始めるのが現実的です。

denops.vimの定義と立ち位置｜DenoでVim/Neovimに動くプラグイン基盤

まずdenops.vimが何を指し、どのような立ち位置の技術なのかを整理します。名前は似ていても役割の異なる構成要素があるため、最初に全体像をつかむと以降の理解が早くなります。

denops.vimが指すもの｜vim-jp発のプラグイン開発エコシステム

denops.vimは、Deno上でVim/Neovim向けプラグインを開発するためのエコシステムで、vim-denops組織を中心に開発・保守されています（同組織は、Vim日本コミュニティであるvim-jpから派生・分離した組織です）。中心的な開発者としてはlambdalisue氏が知られています。公式リポジトリはGitHubのvim-denops/denops.vimで公開されています。「Denoを使ってVim/Neovimプラグインを書くための仕組み一式」を指す総称として使われ、単体のプラグインというより、開発基盤と捉えると実態に合います。商用製品ではなくオープンソースで、誰でも導入・開発に参加できます。

対象エディタはVimとNeovim｜単一コードで両対応できる範囲

denops.vimの対象はVimとNeovimの両方で、ひとつのコードベースで双方に動くプラグインを作れる点が核心です。背景には、VimがVim9 scriptを進める一方、NeovimはLuaへ移行しており、両者の言語的な乖離が広がっている事情があります。denops.vimは下層をDenoに寄せることでこの分断を吸収します。エディタ自体の基本操作に不安がある場合は、Neovimの基本操作と効率的な編集方法を先に押さえておくと、プラグイン開発の理解がスムーズです。

記述言語はTypeScript/JavaScript｜Vim scriptとの役割の違い

denops.vimでは、プラグイン本体のロジックをVim scriptではなくTypeScriptまたはJavaScriptで書きます。型注釈やエディタ補完が効くため、状態管理が複雑なプラグインでも見通しを保ちやすくなります。ただしエディタの設定読み込みやキーマップ定義など、ごく薄い接点ではVim script側の記述も残ります。「重い処理はTypeScript、エディタとの最小限の橋渡しはVim script」という役割分担で考えると整理しやすいです。

本体とdenops_stdの二層構成｜橋渡し役と標準モジュールの関係

denopsは大きく二層に分かれます。ひとつはエディタとDenoをつなぐ本体のvim-denops/denops.vim、もうひとつは開発を補助する標準モジュール群のdeno-denops-std（通称denops_std）です。本体は通信の土台を担い、denops_stdは変数操作や関数呼び出しといった頻出処理をAPIとして提供します。アプリ開発でいうランタイムと標準ライブラリの関係に近く、実際の開発ではdenops_stdを多用します。

denops.vimが解決する課題｜両対応と資産活用を両立する狙い

denops.vimが解こうとしている課題は二つあります。第一に、Vim/Neovim双方で動くプラグインの保守が、言語分断によって難しくなっている点。第二に、Vim scriptという独自言語では、世の中に蓄積されたJavaScript/TypeScriptのライブラリ資産を活かしにくい点です。Denoを共通の実行基盤に据えることで、両対応と資産活用を同時に実現するのが狙いで、これが個人ブログや公式リポジトリで繰り返し語られる導入動機になっています。

denops.vimの内部構造｜channel経由でDenoプロセスとエディタが連携する仕組み

次に、denops.vimが内部でどう動いているかを解説します。仕組みを理解しておくと、後述の制約やトラブルの原因が腑に落ち、設計判断を誤りにくくなります。

Denoプロセスを常駐させる構成｜エディタとは別プロセスでの動作

denops.vimは、エディタの起動時に別プロセスとしてDenoサーバーを立ち上げ、それを常駐させて動かします。プラグインのロジックはエディタ本体の中ではなく、このDenoプロセス側で実行されます。エディタとは独立して動くため、重い処理を回してもエディタの操作を止めにくい一方、プロセス間通信が前提になるという特徴が生まれます。この「別プロセス常駐型」という前提が、以降の通信や制約の出発点です。

channelによるRPC通信｜:h channelで定義される双方向呼び出し

エディタとDenoプロセスの間は、Vim/Neovimが標準で備えるchannelという仕組みを使って通信します。詳細はエディタ内で:h channelを引くと確認できます。channel上でリモート関数呼び出し（RPC）を行い、エディタからDeno側の関数を呼んだり、Deno側からエディタのコマンドを実行したりと双方向にやり取りします。つまりdenopsプラグインは、本質的にはこのRPCを使いやすく包んだものだと理解できます。

授受できるのはJSON変換可能な値のみ｜Lua値が渡せない制約

channelを通る都合上、エディタとDenoの間でやり取りできるのはJSONに変換できる値に限られます。文字列・数値・真偽値・配列・オブジェクトは渡せますが、関数そのものは渡せません。特にNeovimでLuaの関数や一部のLua由来の値をdenops経由で扱おうとするとエラーになる場合があり、これは公式Tipsでも注意点として挙げられています。設計段階で「境界を越えるデータはJSON化できる形にする」と決めておくと、原因不明のエラーを避けられます。

main.tsのmain関数がエントリーポイント｜denops受け取りの流れ

各denopsプラグインは、denops/<プラグイン名>/main.tsに置いたmain関数がエントリーポイントになります。この関数はdenopsオブジェクトを引数として受け取り、その中でエディタから呼び出せる処理を登録します。エディタ側がプラグインをロードするとDenoがmain.tsを読み込み、main関数を実行する、という流れです。慣れるまではこの「main関数にdenopsが渡ってくる」という起点だけ押さえれば十分です。

エディタAPI呼び出しの方法｜call・cmd・evalの使い分け

Deno側からエディタを操作するときは、denopsオブジェクトのメソッドを使います。代表的には、Vim/Neovimの関数を呼ぶdenops.call()、Exコマンドを実行するdenops.cmd()、式を評価して結果を受け取るdenops.eval()の三つです。値が欲しいときはeval、副作用だけならcmd、組み込み関数を使うならcallと使い分けます。これらはすべて非同期で、Promiseを返す点も実装時の前提になります。

denops.vim採用のメリットと注意点｜TypeScript資産とDeno依存のトレードオフ

採用判断には、利点と注意点を並べて天秤にかける視点が欠かせません。ここではメリットと、見落とされやすいコストの両面を具体的に整理します。

型と補完を活かせる開発体験｜大規模プラグインでの保守性

最大の利点は、TypeScriptの静的型付けとエディタ補完をプラグイン開発にそのまま持ち込めることです。引数や戻り値の型が明示されるため、機能が増えても破綻しにくく、リファクタリングの安全性も上がります。TypeScriptの基礎を押さえたい場合はTypeScriptの基本的な特徴とJavaScriptとの違いが参考になります。数百行を超えるような多機能プラグインほど、この保守性の差は効いてきます。

Deno標準ライブラリとnpm資産の活用｜再実装を避ける効果

denopsプラグインはDeno上で動くため、Denoの標準ライブラリを利用できます。さらにDeno 2系ではnpmとの互換性が強化されており、npm上の多くのライブラリも読み込めます。日付処理やパース、HTTP通信といった汎用処理を自前で書き直す必要がなくなり、エディタ拡張という本来やりたい部分に集中できます。Vim scriptでは現実的でなかった外部ライブラリ活用が、ごく自然にできるのは大きな差です。

Vim/Neovim両対応の一本化｜分岐コストを下げる実務効果

VimとNeovimで別々にプラグインを保守するのは、テストもドキュメントも二重化して負担が大きくなります。denops.vimなら基本ロジックを一本化でき、エディタ差はAPIで吸収できるため、メンテナンスの分岐コストを抑えられます。実際、git操作プラグインのgin.vimのように、両エディタのユーザーに同じ機能を届けている実例があります。配布先のユーザー層が両エディタにまたがるほど、この一本化の価値は高まります。

Deno必須という前提コスト｜利用者環境へのインストール要件

注意点として、denops製プラグインを使うには、利用者側の環境にもDenoがインストールされている必要があります。プラグインマネージャを入れれば済むVim scriptプラグインに比べ、導入のハードルが一段上がります。社内配布や不特定多数への配布では、READMEにDenoの導入手順を明記し、未導入時の挙動も案内しておくことが欠かせません。この前提コストを許容できるかが、採用可否の分かれ目のひとつです。

起動オーバーヘッドと非同期前提｜同期処理に向かない場面

別プロセスのDenoを起動するため、エディタ起動直後はサーバーが立ち上がるまでのわずかな待ちが発生します。また通信はすべて非同期で、結果を待つ処理はPromiseで書く必要があります。キー入力に即応する必要があるごく軽量な設定変更などは、Vim scriptで直接書いた方が素直なこともあります。「重い・複雑なロジックほど向き、極小の同期処理には過剰」という性質を踏まえて使いどころを選びます。

Vim script・Lua・coc.nvimとの比較｜denops.vimを選ぶ判断基準

denops.vimは唯一の選択肢ではありません。Vim script、NeovimのLua、Node.js基盤のcoc.nvimと並べ、どの状況でどれを選ぶかの判断基準を示します。

Vim scriptとの比較｜学習資産と移植性のトレードオフ

Vim scriptはVim/Neovim双方で追加ランタイム不要で動き、既存プラグインの蓄積も膨大です。一方で言語仕様に癖があり、複雑なロジックや外部ライブラリ活用には向きません。denops.vimはDenoという前提が増える代わりに、TypeScriptの表現力と資産を得られます。「軽量で依存を増やしたくないならVim script、ロジックが重く保守性を重視するならdenops」という軸で考えると選びやすいです。

NeovimのLuaとの比較｜専用最適化と両対応のどちらを取るか

NeovimのLuaは、エディタ組み込みで追加ランタイムが不要、かつ高速で、Neovim向けには第一候補になりやすい選択肢です。ただしLua製プラグインはNeovim専用で、Vimでは動きません。denops.vimはDeno導入の手間と引き換えにVim/Neovim両対応を実現します。配布対象がNeovimのみで速度最優先ならLua、両エディタのユーザーに届けたいならdenops、という判断が基本線になります。

coc.nvimとの比較｜Node.jsとDenoのランタイム差

coc.nvimもNode.jsの別プロセスでエディタを拡張する点でdenopsと発想が近い仕組みです。違いはランタイムで、coc.nvimがNode.jsなのに対し、denopsはDenoを使います。Denoはファイルやネットワークへのアクセスを既定で制限するパーミッションモデルを持ち、TypeScriptを設定なしで実行できる点が異なります。既存のNode/npmワークフローに乗るならcoc.nvim、Denoの安全設計と手軽さを取るならdenopsという比較になります。

選択基準の早見表｜対象エディタ・言語・配布要件で選ぶ

四つの手段を、対象エディタ・記述言語・追加ランタイムの要否・向く用途で並べると違いが一目で分かります。

表のとおり、両対応とTypeScript活用を同時に満たすのはcoc.nvimとdenops.vimで、その差はランタイムの思想にあります。

向くケースと避けるケース｜判断の分かれ目

denops.vimが向くのは、Vim/Neovim両対応が必要で、ロジックが複雑、かつDeno導入を利用者に許容してもらえるケースです。逆に、Neovim専用で速度を極限まで追う、依存を一切増やしたくない、配布先にDenoを入れてもらえない、といった条件ではLuaやVim scriptが適します。「両対応・複雑・Deno許容」の三条件がそろうほどdenopsの利点が際立つ、と覚えておくと判断が早まります。

denops.vimの導入手順｜Denoのインストールからプラグイン登録までの流れ

ここからは実際にdenops.vimを使い始める手順です。前提のDeno導入、本体の登録、起動確認、デバッグ設定までを順に押さえます。

前提となるDenoのインストール｜公式手順とバージョン管理ツール

最初に行うのはDeno本体のインストールです。Deno公式のインストーラを使う方法のほか、asdfやmiseといったバージョン管理ツール経由で入れる方法もあります。チーム開発ではバージョンをそろえやすい管理ツール経由が無難です。Deno環境の整え方を詳しく確認したい場合はDenoとFreshの開発環境セットアップが参考になります。インストール後はdeno --versionで導入を確認します。

プラグインマネージャでの追加｜runtimepathへの登録要件

denops.vim本体は、dein.vimやlazy.nvimなど任意のプラグインマネージャでvim-denops/denops.vimを追加して導入します。denopsプラグインもVimプラグインの一種であるため、エディタのruntimepath上に存在している必要があります。自作プラグインを試す場合も、そのディレクトリをruntimepathに含める設定が前提です。マネージャを使わない場合は、手動でruntimepathへ追加する点を忘れないようにします。

導入確認の手順｜server#statusでの起動チェック

正しく導入できたかは、次の手順で確認できます。

1. エディタを再起動し、denops.vimが読み込まれる状態にする。
2. エディタ内で:echo denops#server#status()を実行する。
3. サーバーが起動済みを示す状態が返れば、Denoプロセスとの連携が成立している。

状態が返らない場合は、Denoが見つからないかruntimepathの設定漏れが疑われます。まずこのステータス確認を起点に切り分けると効率的です。

デバッグモードの活用｜起動時型チェックと性能影響の見極め

開発初期は、起動時の型チェックなどを有効にするデバッグモードが役立ちます。g:denops#debugを有効化すると、型エラーなどを早期に検出しやすくなります。ただしデバッグモードは性能面のコストがあり、起動が重くなります。公式チュートリアルでも、開発が落ち着いたら解除することが推奨されています。「開発中はオン、普段使いはオフ」という切り替えを習慣にするのが実務的です。

よくある導入トラブル｜Deno未検出と設定漏れの対処

導入でつまずく典型は二つです。ひとつはDenoがPATHに通っておらず、denopsがDeno実行ファイルを見つけられないケース。もうひとつは、プラグインのディレクトリがruntimepathに入っておらず読み込まれないケースです。前者はdeno --versionとPATH設定を、後者はマネージャの設定とディレクトリ構成を見直します。この二点を先に潰すだけで、初期トラブルの多くは解消します。

denops.vimでのプラグイン開発｜main.tsの構成とdenops_std活用の実務

導入できたら、実際にプラグインを書く段階です。ディレクトリ構成、エントリーポイントの実装、denops_stdの使い方、エディタ差の吸収、配布までを実務目線でまとめます。

基本ディレクトリ構成｜denops配下のmain.ts配置ルール

denopsプラグインは、プラグインのルートにdenopsディレクトリを作り、その下にdenops/<プラグイン名>/main.tsを置く構成が基本です。エディタはruntimepath上のこのパスを探してプラグインを認識します。たとえばdps-helloというプラグインならdenops/dps-hello/main.tsとなります。命名とパスがずれるとロードされないため、まずこの配置ルールを正確に守ることが出発点です。

main関数とdispatcherの実装｜エディタから呼ぶAPIの定義

main.tsでは、denopsを引数に取るmain関数をエクスポートし、その中でdenops.dispatcherにエディタから呼べる処理を登録します。dispatcherに登録した関数は、エディタ側から名前を指定して呼び出せます。受け取る引数はJSON変換可能な値である必要があるため、複雑な構造はあらかじめ単純な形に整えて渡します。この「dispatcherに公開APIを定義する」という型が、開発の基本パターンになります。

denops_stdの主要モジュール｜variable・function・autocmdの利用

実装ではdenops_stdの各モジュールを多用します。グローバル変数などを扱うvariable、Vim/Neovimの組み込み関数を呼ぶfunction、自動コマンドを登録するautocmd、複数操作をまとめて効率化するbatchなどが代表例です。これらを使うと、低レベルのcall/cmdを直接書くより安全かつ簡潔に記述できます。まずは変数・関数・autocmdの三つを押さえれば、実用的なプラグインの大半は組み立てられます。

Vim/Neovim差異の吸収｜denops.metaでの分岐実装

両対応を謳っても、Vim固有・Neovim固有のAPIを使いたい場面は出てきます。その際はdenops.metaから実行中のホスト情報を取得し、VimとNeovimで処理を分岐します。共通処理は一本化しつつ、差が出る箇所だけ条件分岐する設計にすると、コードの重複を抑えられます。分岐点を局所化しておくことが、両対応プラグインを長く保守するうえでの実務的なコツです。

テストと配布の進め方｜GitHub公開とバージョン運用

完成したプラグインはGitHubで公開するのが一般的で、利用者は通常のVimプラグインと同じくマネージャ経由で導入します。Deno標準のテスト機能を使えば、ロジック部分を自動テストで検証できます。READMEには必須のDenoバージョンや権限要件を明記し、破壊的変更時はタグでバージョンを管理すると利用者が安全に追従できます。公開後も、エディタとDenoの更新に合わせた継続的な動作確認が運用上の前提になります。

denops.vimの運用とエコシステム｜バージョン固定と代表プラグインの実例

最後に、運用フェーズで効く知識をまとめます。Denoの更新に振り回されないための固定、権限の考え方、そして実在するdenops製プラグインと業務活用の観点です。

Denoバージョン固定の必要性｜更新による破壊的変更の回避

denopsプラグインはDenoの挙動に依存するため、Denoが自動更新されると、ある日突然プラグインが動かなくなるリスクがあります。これを避けるには、使用するDenoのバージョンを固定する運用が有効です。バージョン管理ツールでプロジェクトごとにDenoを固定したり、denopsが使うDeno実行ファイルのパスを明示したりする方法があります。安定運用を重視するなら、Denoを意図せず最新へ上げない仕組みを最初に用意しておきます。

キャッシュ位置の管理｜DENO_DIRと依存解決の安定化

Denoはダウンロードした依存をキャッシュに保存し、その場所はDENO_DIR環境変数で制御できます。キャッシュ位置が環境ごとにばらつくと、依存解決の挙動が安定しないことがあります。DENO_DIRを明示的に固定しておくと、複数マシンやCI環境でも同じ依存状態を再現しやすくなります。Denoのバージョン固定とキャッシュ位置の固定はセットで考えると、運用時の「動いたり動かなかったり」を減らせます。

パーミッションモデルとの関係｜allowフラグの考え方

Denoは、ファイルやネットワークへのアクセスを既定で禁止し、--allow-netや--allow-readなどのフラグで明示的に許可するパーミッションモデルを採用しています。denopsはエディタ連携に必要な権限を付与してDenoを起動しますが、サードパーティ依存が過剰な権限を要求していないかは意識すべき点です。安全性を重視するなら、利用するライブラリが必要とするアクセス範囲を把握し、不要に広い権限を前提にしない設計を心がけます。

代表的なdenops製プラグイン｜ddu・ddc・gin・skkeletonの実例

denops.vimの実力は、実在する有力プラグインを見ると分かりやすいです。代表例として次のようなものがあります。

• ddu.vim：あいまい検索やリスト表示を担う、拡張性の高いUIフレームワーク。
• ddc.vim：補完機能を提供するフレームワークで、各種補完ソースを組み合わせられる。
• gin.vim：Vim/Neovim内でgit操作を完結させるプラグイン（lambdalisue氏作）。
• skkeleton：日本語入力方式SKKをエディタ内で実現する入力プラグイン。

これらが日常的に使われている事実が、denops基盤の実用性を裏づけています。

チーム・業務開発での活用観点｜保守性とCIを意識した運用

業務でエディタ拡張を内製する場合、denops.vimはTypeScriptで書ける分、Web開発者がそのままレビューや保守に加わりやすい利点があります。CIではDenoの型チェックやテストを自動実行し、エディタ・Denoの更新に対する回帰を早期に検知できます。社内配布ではDenoバージョンと権限要件を標準化し、READMEと合わせて運用ルールを定めておくと属人化を防げます。両対応・型・CIという強みは、個人利用よりむしろチーム開発で効いてきます。

denops.vimに関するよくある質問

denops.vimの導入や開発でよく寄せられる疑問を、要点を絞って解説します。検討段階で迷いやすいポイントを中心にまとめました。

denops.vimとdenopsの違いは何ですか？

「denops」はDenoでVim/Neovimプラグインを書くエコシステム全体を指す総称で、「denops.vim」はそのうちエディタとDenoをつなぐ本体プラグイン（GitHubのvim-denops/denops.vim）を指します。さらに開発を補助する標準モジュール群がdeno-denops-std（denops_std）です。会話では区別せず使われることも多いですが、厳密には「総称＝denops／本体＝denops.vim／標準ライブラリ＝denops_std」と整理すると正確です。

denops.vimの利用にDenoは必須ですか？

必須です。denops.vimはプラグインのロジックをDenoプロセス上で実行する仕組みのため、利用者の環境にDenoがインストールされていないと動作しません。これはプラグインの作者だけでなく、そのプラグインを使う側にも当てはまります。配布時はREADMEにDenoの導入手順と必要バージョンを明記し、未導入の場合の案内も用意しておくと、利用者がつまずきにくくなります。

Vim scriptが書けなくてもプラグインを作れますか？

ロジックの大半はTypeScript/JavaScriptで書けるため、Vim scriptに不慣れでもプラグイン開発は可能です。実際、Vim scriptに馴染めずdenops.vimを選ぶ開発者は少なくありません。ただし、キーマップ定義や設定の読み込みなど、エディタとの最小限の接点でVim scriptの基礎知識が役立つ場面はあります。まずはTypeScript側に集中し、必要に応じてVim scriptを少しずつ覚える進め方が現実的です。

denops製プラグインは動作が遅くなりませんか？

別プロセスのDenoを起動するため、エディタ起動直後にサーバーが立ち上がるまでのわずかな待ちは発生します。一方、処理自体は非同期で実行されるため、重いロジックを動かしてもエディタの操作を止めにくい利点があります。なお、開発用のデバッグモードは型チェックなどで起動が重くなるため、普段使いでは解除するのが推奨です。「起動の軽い待ちはあるが、実行は実用的」と捉えるのが実態に近いです。

VimとNeovimのどちらでも同じように動きますか？

基本的には単一のコードベースで両方に対応でき、共通の機能は同じように動きます。ただしVim固有・Neovim固有のAPIを使う部分では、denops.metaでホストを判定して処理を分岐する必要があります。差異を吸収する設計になっているかは個々のプラグイン次第のため、両対応をうたっていても、利用前に対応エディタの記載を確認すると安心です。自作する場合は、分岐箇所を局所化しておくと保守が楽になります。

関連記事

• Freshフレームワークの概要とその特徴: DenoとPreactを活用した最新技術：denopsと同じDenoエコシステムの広がりを、Webフレームワーク側から理解できます。
• TypeScriptの基本的な型と型推論、型注釈について：denopsプラグインを書く言語であるTypeScriptの型を、基礎から押さえられます。