独自スクリプト言語をVS Code拡張でサポートThis article explains how to build a VS Code extension that adds editor…

Developers who create their own scripting or configuration languages often find that adoption depends heavily on tooling. A language may be well designed, but without syntax highlighting, autocompletion, and error checking, writing code in it feels like editing plain text. Visual Studio Code has become a common target for closing that gap because its extension model lets language authors layer editor support onto an existing, widely used editor rather than building a bespoke IDE. This article walks through how such an extension is assembled and what each layer contributes.

The most approachable starting point is syntax highlighting. VS Code inherits the TextMate grammar system, in which a JSON or PLIST file describes patterns—usually regular expressions—that map fragments of source code to scope names such as keyword.control or string.quoted. The editor's active color theme then decides how each scope is rendered. Grammars are registered through the extension's package.json using the contributes.grammars field, alongside a contributes.languages entry that associates a language identifier with file extensions. A companion language configuration file handles editor niceties that do not require understanding the code's meaning, including comment tokens for the toggle-comment command, bracket pairs, auto-closing quotes, and indentation rules. For many small languages, these declarative files alone deliver a noticeably better experience without any executable logic.

Deeper features—completion suggestions, hover documentation, go-to-definition, rename, and live diagnostics—require the editor to actually understand the language. This is where the Language Server Protocol, or LSP, becomes relevant. LSP was introduced by Microsoft and is now an open standard that separates the language intelligence from the editor. A language server is a standalone process that communicates with the editor over JSON-RPC, receiving notifications about document changes and responding to requests such as textDocument/completion or textDocument/hover. The practical benefit is decoupling: the same server can, in principle, power other LSP-capable clients like Neovim, Emacs, or Sublime Text, so the effort invested is not locked to a single editor. On the VS Code side, the vscode-languageclient library handles the client wiring, while vscode-languageserver provides a Node.js scaffold for the server, though servers can be written in any language that speaks the protocol.

A typical project therefore combines both approaches. The declarative grammar and language configuration handle fast, purely syntactic concerns, and the language server supplies semantic features that depend on parsing and analyzing the code. Authors frequently reuse an existing parser or write a lightweight one, then expose its results through LSP handlers. VS Code also supports semantic token highlighting, an LSP-driven mechanism that refines the coarse TextMate coloring using real parse information, which is useful when regular expressions cannot reliably distinguish, for example, a variable from a function call.

Getting started is streamlined by the Yeoman generator generator-code, which scaffolds either a basic language extension or a language server example. The generated project includes a package.json declaring activation events, contribution points, and dependencies, plus a launch configuration for debugging the extension in an Extension Development Host window. Once the extension works locally, it can be packaged with the vsce tool into a .vsix file and published to the Visual Studio Marketplace or the vendor-neutral Open VSX Registry, which editors such as VSCodium and Gitpod rely on.

It is worth noting some adjacent developments that shape this area. Tree-sitter, an incremental parsing library originally popularized by GitHub and Neovim, is increasingly used to generate fast, error-tolerant grammars, and interest in tree-sitter-based highlighting within the VS Code ecosystem has grown, although TextMate grammars remain the default. The broader trend is that LSP has effectively standardized language tooling across editors, meaning a well-built server is a durable investment. There is also an emerging Debug Adapter Protocol that plays a similar decoupling role for debugging, should a language need step-through support later.

In summary, adding editor support for a custom language in VS Code is best understood as a layered task: declarative files for highlighting and basic editing behavior, followed by an optional but powerful language server for semantic intelligence. Because these pieces build on open protocols, the resulting work is likely to remain useful beyond a single editor, which is a meaningful consideration for anyone investing in a niche or in-house language.